slush [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-12-16 to 2015-05-06
💬 Posted a total of 81 messages
📚 Participated in the following categories: Bitcoin-development, BIP 15
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6

Profile Code

nprofile1qqswkl98j5zhef72hhn02sw8g8nxr5qng9ynfevnfshqf3n8wcjunxspz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsc0taxz

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1ad7209g90jnu400x74quws0xv8gpxs2fxnjexnpwqnrxwa39exdq5gl2p6

Show more details

Last Notes

2023-06-07 17:33:00

- reply

📅 Original date posted:2015-05-06
📝 Original message: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-list at 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 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/20150507/6bdab3de/attachment.html>

2023-06-07 17:31:31

- reply

📅 Original date posted:2015-03-12
📝 Original message:On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150312/318ad491/attachment.html>

2023-06-07 17:29:06

- reply

📅 Original date posted:2015-01-23
📝 Original message: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 <etotheipi at 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 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/20150123/2562323d/attachment.html>

2023-06-07 17:29:05

- reply

📅 Original date posted:2015-01-23
📝 Original message: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 <etotheipi at 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 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/20150123/be814f81/attachment.html>

2023-06-07 17:29:04

- reply

📅 Original date posted:2015-01-23
📝 Original message: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 <gmaxwell at gmail.com> wrote:
> On Fri, Jan 23, 2015 at 5:40 PM, slush <slush at centrum.cz> wrote:
> > 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.
>
> I'm quite familiar with embedded development :), and indeed trezor MCU
> is what I would generally consider (over-)powered which is why I was
> somewhat surprised by the numbers; I'm certainly not expecting you to
> perform dynamic allocation... but wasn't clear on how 40 minutes and
> was I just trying to understand. Using a table to avoid retransmitting
> reused transactions is just an optimization and can be done in
> constant memory (e.g. falling back to retransmission if filled).
>
> So what I'm understanding now is that you stream the transaction along
> with its inputs interleaved in order to reduce the memory requirement
> to two midstates and a value accumulator; requiring resending the
> transaction... so in the worst case transaction (since you can't get
> in more than about 800 inputs at the maximum transaction size) each
> input spending from (one or more, since even one would be repeated)
> 100kb input transactions you might send about 800MBytes of data, which
> could take a half an hour if hashing runs at 45KB/s or slower?
>
> (If so, okay then there isn't another thing that I was missing).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/c2669876/attachment.html>

2023-06-07 17:29:03

- reply

📅 Original date posted:2015-01-23
📝 Original message:On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell <gmaxwell at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/26b40164/attachment.html>

2023-06-07 17:29:03

- reply

📅 Original date posted:2015-01-23
📝 Original message: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 <gmaxwell at 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/20ba09ee/attachment.html>

2023-06-07 17:29:02

- reply

📅 Original date posted:2015-01-23
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/30a6ffb5/attachment.html>

2023-06-07 17:29:02

- reply

📅 Original date posted:2015-01-23
📝 Original message:> 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 <etotheipi at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> T
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150123/0b4fa4b3/attachment.html>

2023-06-07 17:24:59

- reply

📅 Original date posted:2014-08-07
📝 Original message: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 <pedro at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140808/d73a8281/attachment.html>

2023-06-07 17:24:58

- reply

📅 Original date posted:2014-08-07
📝 Original message: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 <luke at 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=153845071&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20140808/bf203262/attachment.html>

2023-06-07 17:24:04

- reply

📅 Original date posted:2014-07-17
📝 Original message:On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik <jgarzik at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140717/de5a6fa8/attachment.html>

2023-06-07 17:23:19

- reply

📅 Original date posted:2014-06-25
📝 Original message:On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140625/c0bd2c59/attachment.html>

2023-06-07 17:23:16

- reply

📅 Original date posted:2014-06-24
📝 Original message: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 <mike at 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 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/20140624/ef92af63/attachment.html>

2023-06-07 17:23:09

- reply

📅 Original date posted:2014-06-19
📝 Original message:On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140619/85314caf/attachment.html>

2023-06-07 17:20:37

- reply

📅 Original date posted:2014-05-03
📝 Original message: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.biocca at 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 <voisine at 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 <gojomo at 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 about it,
> >>> the more I like it. The main thing going for it is the fact that it's
> >>> part of the name bitcoin. If Bitcoin is the protocol and network, bits
> >>> are an obvious choice for the currency unit.
> >>>
> >>> I would like to propose using Unicode character U+0180, lowercase b
> >>> with stroke, as the symbol to represent the microBTC denomination,
> >>> whether we call bits or something else:
> >>> http://www.fileformat.info/info/unicode/char/0180/index.htm
> >>>
> >>> Another candidate is Unicode character U+2422, the blank symbol, but I
> >>> prefer stroke b.
> >>> http://www.fileformat.info/info/unicode/char/2422/index.htm
> >>>
> >>> Aaron
> >>>
> >>> There's no trick to being a humorist when you have the whole
> >>> government working for you -- Will Rodgers
> >>>
> >>>> On Apr 21, 2014 5:41 AM, "Pieter Wuille" <pieter.wuille at gm...> wrote:
> >>>>
> >>>>> On Apr 21, 2014 3:37 AM, "Un Ix" <slashdevnull at ...> wrote:
> >>>>>
> >>>>> Something tells me this would be reduced to a single syllable in
> common
> >>>>> usage I.e. bit.
> >>>>
> >>>> What units will be called colloquially is not something developers
> will
> >>>> determine. It will vary, depend on language and culture, and is not
> >>>> relevant to this discussion in my opinion.
> >>>>
> >>>> It may well be that people in some geographic or language area will
> end up
> >>>> (or for a while) calling 1e-06 BTC "bits". That's fine, but using
> that as
> >>>> "official" name in software would be very strange and potentially
> confusing
> >>>> in my opinion. As mentioned by others, that would seem to me like
> calling
> >>>> dollars "bucks" in bank software. Nobody seems to have a problem with
> >>>> having colloquial names, but "US dollar" or "euro" are far less
> ambiguous
> >>>> than "bit". I think we need a more distinctive name.
> >>>>
> >>>> --
> >>>> Pieter
> >>>
> >>>
> ------------------------------------------------------------------------------
> >>> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >>> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >>> unparalleled scalability from the best Selenium testing platform
> available.
> >>> Simple to use. Nothing to install. Get started now for free."
> >>> http://p.sf.net/sfu/SauceLabs
> >>> _______________________________________________
> >>> Bitcoin-development mailing list
> >>> Bitcoin-development at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >>>
> >>
> >>
> ------------------------------------------------------------------------------
> >> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> >> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> >> unparalleled scalability from the best Selenium testing platform
> available.
> >> Simple to use. Nothing to install. Get started now for free."
> >> http://p.sf.net/sfu/SauceLabs
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> > Instantly run your Selenium tests across 300+ browser/OS combos. Get
> > unparalleled scalability from the best Selenium testing platform
> available.
> > Simple to use. Nothing to install. Get started now for free."
> > http://p.sf.net/sfu/SauceLabs
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos. Get
> unparalleled scalability from the best Selenium testing platform available.
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> 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/20140503/0822abf5/attachment.html>

2023-06-07 17:18:20

- reply

📅 Original date posted:2014-04-09
📝 Original message:We definitely *need* lightweight bitcoin router / "core" which can be
easily deployed anywhere. No disagreement here.
I just wanted to remind that there're actually much more running nodes
*already* and maybe converting those hidden nodes to publicly reachable
nodes may be way easier than attracting fresh instances.
To the idea of bundled core with SPV clients - it won't improve anything,
in my opinion. SPV wallets are not running long-term (maybe Multibit team
has any better stats) so blockchain catching will turn the computer to be
unusable everytime user starts the wallet; that's exactly the reason why
people choose SPV wallets over full blockchain wallets.
Not saying that SPV clients usually aren't reachable from outside, which
turns the topic back to my ideas about motivating users to expose their
existing instances over Internet.
Marek
On Wed, Apr 9, 2014 at 10:35 PM, Wladimir <laanwj at gmail.com> wrote:
>
>
> On Wed, Apr 9, 2014 at 10:12 PM, slush <slush at centrum.cz> wrote:
>
>> Maybe there're other ideas how to improve current situation without needs
>> of reworking the architecture.
>>
>
> Nothing I've proposed here would require larger changes to the
> architecture then were already planned. After SPV lands we are going to
> split off the wallet, and that will need an interface to an bitcoind to
> allow 'running with full node'. If that can be generalized to be useful for
> other (SPV) clients as well, that would be useful, hence I asked for input.
>
> It of course doesn't preclude also looking for other solutions.
>
> Wladimir
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140409/a49a8414/attachment.html>

2023-06-07 17:18:18

- reply

📅 Original date posted:2014-04-09
📝 Original message: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 <slush at 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 <gmaxwell at gmail.com>wrote:
>
>> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <justusranvier at 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 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/20140409/e99a782c/attachment.html>

2023-06-07 17:18:18

- reply

📅 Original date posted:2014-04-09
📝 Original message: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 <gmaxwell at gmail.com> wrote:
> On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier <justusranvier at 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 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/20140409/477817a3/attachment.html>

2023-06-07 17:18:06

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Tue, Apr 8, 2014 at 5:58 PM, Andreas Schildbach <andreas at schildbach.de>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 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.
>
> There is no "bare minimum". Either you implement the "BIP" fully or not.
>
I didn't mean "Bare minimum of some spec", but "spec describing bare
minimum", which is different. I'm sorry for confusion.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/792dd287/attachment.html>

2023-06-07 17:18:05

- reply

📅 Original date posted:2014-04-08
📝 Original message:On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach <andreas at schildbach.de>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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/5cd11bda/attachment.html>

2023-06-07 17:17:55

- reply

📅 Original date posted:2014-04-23
📝 Original message: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 of BIP64, but we'll communicate it as soon as we'll write down that
idea to some more specific format.
Marek
On Wed, Apr 23, 2014 at 9:36 PM, Tamas Blummer <tamas at bitsofproof.com>wrote:
> Pieter suggested in IRC couple of months ago to append key birth to key
> serialization in xprv.... at unixtime format.
>
> What about picking this idea up in BIP64? It would greatly help the
> importing client.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/db8776a4/attachment.html>

2023-06-07 17:17:54

- reply

📅 Original date posted:2014-04-23
📝 Original message: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.nolan at gmail.com> wrote:
> On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak <stick at 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 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/20140423/73fa1ccd/attachment.html>

2023-06-07 17:17:50

- reply

📅 Original date posted:2014-04-08
📝 Original message: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 <slush at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140408/8f510949/attachment.html>

2023-06-07 17:17:49

- reply

📅 Original date posted:2014-04-08
📝 Original message: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 <slush at 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.wuille at gmail.com>wrote:
>
>> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at 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 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/20140408/3409249a/attachment.html>

2023-06-07 17:17:24

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn <mike at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/08a39900/attachment.html>

2023-06-07 17:17:24

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchevêque <elarch at gmail.com> wrote:
> On Fri, Apr 4, 2014 at 4:56 PM, slush <slush at centrum.cz> 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.
>>
>> 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.
>>
>>
> I'm probably very naive, but the fact that the authentication key is your
> Bitcoin address was for me a great feature :)
> What are the risks associated of id yourself with a bitcoin address you
> plan to use on the website for transaction ?
>
>
Ideally you should not reuse the address, so the website will need more
addresses or bip32 xpub anyway.
By using wallet address and accidentally using such address in some
transaction, you may be leaking your identity with with other business -
think about Silkroad (sorry Mike :-).
By using derived key, you can be sure your identity won't be linked with
any other activity on the internet.
I mean, what is the difference between doing that, and id with a login/pass
> and add your bitcoin address in a settings field ? (knowing you could
> always find a mechanism to transfer the account to another bitcoin address
> if needed)
>
> *) You can change address in settings field. It's not so easy when address
== your identity.
*) There's plenty of websites which do need authentication but don't need
to know your bank account / bitcoin address at all. Facebook, Gmail,
Twitter ...
Ideally, the user should not care about "what address do I use for this
service", because in the future user should not care about addresses at all
(handling of private keys is already eliminated by bip32, handling of raw
addresses may be eliminated soon by bip70 or similar solutions).
I can imagine that the private/public data will be derived automatically
from some secret master key (ideally derived from bip32 seed, which is
already secured well by the user) and the URL of the service.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/5c5b14cb/attachment.html>

2023-06-07 17:17:23

- reply

📅 Original date posted:2014-04-04
📝 Original message: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 <elarch at 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 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/20140404/5fdb03ea/attachment.html>

2023-06-07 17:17:23

- reply

📅 Original date posted:2014-04-04
📝 Original message:On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn <mike at plan99.net> 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 to use their phone as a second factor - *the simplest
> second factor possible* - was a huge uphill battle that most users just
> didn't care about. People like passwords. If you can find a way to make
> something that's better than a password but just as convenient, fantastic!
> But I don't think Bitcoin addresses are such a thing.
>
>
With all respect to your experience, I think you're wrong, for one reason.
2fa auth doesn't *remove* the need of password. It actually *adds* yet
another layer, which complicates stuff for average user. Common user, which
is not paranoid enough (like me) simply don't think he has anything to
hide, so they simply don't see why they should *complicate* their live with
2fa, backing up their phone etc.
In the oposite, authentication based on bitcoin wallet could make the
process much easier and remove the need of passwords at all, because people
*already* care about safe storage of their coins.
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140404/3012d59c/attachment.html>

2023-06-07 17:16:20

- reply

📅 Original date posted:2014-03-28
📝 Original message: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.wuille at gmail.com>wrote:
> On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at 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 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/20140328/8b081833/attachment.html>

2023-06-07 17:16:05

- reply

📅 Original date posted:2014-03-25
📝 Original message: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 <etotheipi at gmail.com> wrote:
> I would echo the need for some kind of moderation.
>
> I believe Peter Todd is an extremely intelligent individual, who has a
> lot to offer the Bitcoin community. He has a firm grasp of a lot of
> really deep Bitcoin concepts and his *technical* insight is generally
> positive. Technically. But the way he communicates on this list is
> *extremely* corrosive and breeds hostility. It makes it a scary place
> to discuss things, with frequent, public ridicule of everything posted.
>
> I agree that I would rather have a friendly environment to discuss
> technicals, even if it means losing additional technical insight.
> People who would explicitly insult other contributors intelligence and
> character on a public list should be subject to some kind of negative
> reinforcement. Maybe there's solutions other than outright banning.
>
> -Alan
>
>
>
> On 03/25/2014 01:37 PM, Jeff Garzik wrote:
> > On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd <pete at petertodd.org> wrote:
> >> For someone with 'Chief Scientist' as their job title, I'm surprised you
> >> think so little of hard evidence and so much of idol worshipping.
> > Peter, take this unprofessional, personal crap off-list.
> >
> > Mike's anecdote of hostility is not an isolated one. Just today, a
> > bitcore developer commented on "Peter Todd's ..apocalyptic vision
> > and... negative view on bitcoin" which turned off some other
> > developers from participating more interactively.
> >
> > As I commented on IRC, open source projects are no strangers to people
> > who simultaneously (a) make useful contributions and (b) turn
> > potential contributors away with an abrasive or hostile attitude
> > toward others. It's an unsolved problem in OSS, that I saw for 15+
> > years in the Linux kernel community.
> >
> > For this list, as Mike suggested on IRC, introducing an openly stated
> > moderation policy may be the one route.
> >
>
>
>
> ------------------------------------------------------------------------------
> 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/13534_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/20140325/5e203215/attachment.html>

2023-06-07 17:15:38

- reply

📅 Original date posted:2014-03-13
📝 Original message:Internal accounting in satoshis.
Display based on locale.
Problem solved.
On Thu, Mar 13, 2014 at 5:30 PM, Tamas Blummer <tamas at bitsofproof.com>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 2013
> https://bitcointalk.org/index.php?topic=149150.0
> and received the most votes.
>
> I remembered this last time on this list here:
>
> http://sourceforge.net/p/bitcoin/mailman/message/31640769/
>
> Regards,
>
> Tamas Blummer
> Founder, CEO
> Bits of Proof
> http://bitsofproof.com
>
>
>
> ------------------------------------------------------------------------------
> 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/13534_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/20140313/bdd70ddb/attachment.html>

2023-06-07 17:12:21

- reply

📅 Original date posted:2014-01-20
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/bd7b8cb2/attachment.html>

2023-06-07 17:12:21

- reply

📅 Original date posted:2014-01-20
📝 Original message:On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr <luke at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140120/1c516e00/attachment.html>

2023-06-07 17:08:31

- reply

📅 Original date posted:2013-11-06
📝 Original message:> 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 friend.
Slush
Sent from mobile phone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131106/34efeea8/attachment.html>

2023-06-07 17:08:30

- reply

📅 Original date posted:2013-11-02
📝 Original message:Glad to see that there are more and more people wanting to replace
passwords with digital signatures.
Although such method has been already used on other websites like Eligius
or bitcoin-otc, I dont think theres any standard way to doing so yet.
Two comments to your proposal:
A) message-to-be-signed need to be carefully composed to be both structured
and human readable. It should contain at least:
Desired username/identity handler
Server identifier (url)
Timestamp to prevent replay attack
Server challenge
Then the user can see what he's signing, instead of signing some binary
blob 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
On Sat, Nov 2, 2013 at 6:01 AM, <bitcoingrant at gmx.com> wrote:
> Passwords are inefficient by design: frequently we hear news from Sony,
> Square Enix, Adobe, and various others about passwords being compromised,
> databases being copied and stolen. This story remains true in the Bitcoin
> space. In light of the recent Bitcointalk forum breach echoes an increasing
> need for passwords to become a thing of the past.
>
>
>
> In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are
> delighted to introduce the Message Signing based authentication method.
>
>
>
> In brief, the authentication work as follows:
>
>
>
> Server provides a token for the client to sign.
>
> client passes the signed message and the bitcoin address back to the
> server.
>
> server validates the message and honors the alias (optional) and bitcoin
> address as identification.
>
>
>
> http://forums.bitcoingrant.org/
>
>
>
> Above is a proof of concept forum that utilize this authentication method.
> Following Kerckhoffs's principle, this forum only stores the signed message
> and bitcoin address the users provide the first time they use the site,
> both are public information. In addition, there is no database, everything
> is simply an RSS feed. For the sake of usability we have included a redis
> for the sessions, at the cost of additional exposure to potential risks:
> users no longer need to sign a token every time they wish to post.
>
>
>
> All source code will be available on github in the next few days.
>
>
>
> We welcome any feedback or suggestions.
>
>
>
>
>
> ------------------------------------------------------------------------------
> 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=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131102/31897bcb/attachment.html>

2023-06-07 17:08:23

- reply

📅 Original date posted:2013-11-01
📝 Original message:Hi Brooks,
I've been already thinking about eat -> cat typing mistake. Actually there
may be simplier solution than having wordlist with duplicated words.
Because there's already a mapping of similar characters in the source code
(currently only in unit test, but it can be moved), when user type a word
which isn't in wordlist, application may try to use such mapping to find a
combination which actually is in the mapping. This may be disambiguous in
some cases, but giving a choice between few words may be better than hard
fail. And it is actually quite easy to implement. Although I think
application can do such smart suggestions and help user to recover badly
written mnemonic, I don't think it is necessary to standardize such method
directly into BIP. It may or may not be implemented by developers and it is
just nice to have feature.
Example:
user type ear, but it isn't in wordlist.
Regards the mapping,
E is similar to A, C, F, O
A is similar to E, C, O
R is similar to B, P, H
So application can calculate combinations of possible characters:
a) when app consider than the the user mistyped only one character
AAR, CAR, FAR, OAR
EER, ECR, EOR
EAB, EAP, EAH
b) when app consider than user maybe mistyped more characters, it may do
full combination matrix
AEB, ACB, AOB, ... OEH, OCH, OOH
and then ask user to select only these combinations which are actually
presented in the wordlist. In this particular case it may be only CAR or
FAR (both cannot be in the wordlist because of rules in similarity).
Marek
On Fri, Nov 1, 2013 at 9:14 PM, Brooks Boyd <boydb at midnightdesign.ws> wrote:
> I was inspired to join the mailing list to comment on some of these
> discussions about BIP39, which I think will have great use in the Bitcoin
> community and outside it as a way to transcribe binary data.
>
> The one thought I had as the discussions about similar characters are
> resulting in culling words from the list, is that it only helps to validate
> input, not help the user if it is incorrect.
>
> For example, if both "cat" and "eat" were in the word list, and someone
> wrote down "eat", but later mis-translated it and put "cat" back into
> translator, the result would be a checksum error; "cat" is a different
> number, so the checksum would fail.
>
> As it currently stands, "cat" would not be a valid word ("eat" is the real
> word, and no other number is "cat"), so the translator can throw a
> different error which is more helpful (i.e. "'cat' isn't a valid word
> choice), but still doesn't get the user to the proper translation.
>
> What about if the wordlist included those "words that are so similar to
> each other that we only kept one of them" and had them all refer to the
> same number? I propose the wordlist have the possibility of multiple words
> on a single line, with the first word on the line being the "primary" or
> "real" word to be used, with the other similar words be included so that a
> translation program if it wanted to assist the user could fix their input
> for them (verbosely or not), along the lines of "'cat' isn't a valid word
> choice; assuming you meant 'eat', which is valid". You might still hit a
> checksum error if that similar word is still the wrong word, but as it
> stands now, I know you culled a bunch of words from the wordlist as "too
> similar", but if I want to try and help the user fix a bad input, I need to
> write a translation program with a full english dictionary alongside the
> BIP39 dictionary.
>
> I'd be willing to create a pull request for such an update, but before I
> delve into that, does this sound like a good idea? I could see it devolving
> into a slippery slope if every number in the 2048 set had a dozen word
> variations (misspellings, similar words, slang terms for the real word,
> etc.) which could get confusing of how similar is similar enough to be
> added as an alternate, and the standard would need to be clear that when
> translating binary to words, you only use the "main" word for that row, not
> any of the variations.
>
> MidnightLightning
>
>
> > 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
>
>
> ------------------------------------------------------------------------------
> 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=65839951&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131102/26d9c9a1/attachment.html>

2023-06-07 17:08:05

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 9:32 PM, Jorge Timón <jtimon at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/af3f3b9b/attachment.html>

2023-06-07 17:08:04

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 9:23 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/c0ec8fb3/attachment.html>

2023-06-07 17:08:03

- reply

📅 Original date posted:2013-10-24
📝 Original message: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 <
matthewmitchell at 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 <stick at 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 <stick at 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=51271111&iu=/4140/ostg.clktrk
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at 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=51271111&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131024/c69dcea3/attachment.html>

2023-06-07 17:08:02

- reply

📅 Original date posted:2013-10-31
📝 Original message: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
> structures. I do think we first need to see what possibilities and
> developments are possible related to it.
Although many strange practices how to use whole bip32 space are possible,
I think that we may (should?) agree on some "good enough" way how to
discover already used addresses in bip32 space. I read Electrum sources
about bip32 and I see that Electrum still uses quite flat structure (fixed
amount of branches, indexes from 0 to n), which is of course very sane way.
So if I migrate seed to another (non-Electrum) software, I only need to
discover close neighbourhood of the path "0", similarly like Electrum is
doing with "gap limit" in plain old Electrum algorithm, except in two
dimensions (paths 0, 1, 2, 3, 4, 5, 0/0, 0/1, 0/2, 0/3, 0/4, 0/5, 1/0, 1/1,
...5/5 for gap limit "5"). I don't say such operation is cheap, but this
discovery needs to be done only during the import.
For the reason that I think this is the only sane algorithm of general use
of bip32 space, I still don't see why we do need some extra metadata. I
would understand this if Electrum will use for some strange reason
addresses in higher address space like 2^32-1 or so, but this is not going
to happen at least in Electrum.
> I understand that in
> the case of Electrum, there is a strong reason to want this
> encapsulated together with the seed, but it's not really a requirement
> for most wallets.
Well, I can imagine that the bip32 compatible software will do full scan of
address space using some gap factor (actually I think "5" is too low by
default) or it can ask for wallet metadata like which software used such
tree before, to speedup scanning process.
I see that Thomas wants to make this automatic and hidden to user and
generally I agree that hiding the compexity to user is a good practice, but
actually this particular situation sounds to me as an exact oposite of
original statement "no metadata in mnemonic".
> Regarding other requirements, I wonder why we want the transformation
> to be bidirectional? If it is just about generating master seeds, one
> direction should be enough, and allows far nicer properties w.r.t.
> security. If we do settle on a standard for 'brainwallets',
ECDSA has one very nice option - (almost) any random data can be used as a
private key. There are very nice schemas possible by using this feature and
requiring private key to be specially crafted just because the user wanted
to use mnemonic schema is very strong limitation to me.
To be specific, we (in cooperation with / inspired by Timo Hanke) developed
method how to prove that the seed generated by Trezor has been created
using combination of computer-provided entropy and device-provided entropy,
without leaking full private information to other computer, just because we
want Trezor to be blackbox-testable and fully deterministic (seed
generation is currently the only operation which uses any source of RNG).
To limit the complexity of such algorithm it is better to produce plain
seed (128, 192 or 256 bits, depends on settings) and then transform the
result of such "deterministic seed" to mnemonic, so for us the
bi-directionality is quite strong requirement. *Maybe* it would be possible
to combine such algorithm and one-way mnemonic together, but it would
complicate the design and I'm sure you understand that we want to keep
things as clear and simple as possible, especially while handling with seed
generation.
> I would strongly prefer if it had at least some strengthening built-in, to
> decrease the impact of worst-case situations.
Agree (hardening is default in bip39).
Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/35ff057a/attachment.html>

2023-06-07 17:08:02

- reply

📅 Original date posted:2013-10-31
📝 Original message:On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin <thomasv1 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131031/22ee437e/attachment.html>

2023-06-07 17:08:01

- reply

📅 Original date posted:2013-10-26
📝 Original message: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 <thomasv1 at 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=60135991&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20131026/0bdf1770/attachment.html>

2023-06-07 17:08:00

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1 at 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.
>
>
On topic of "it wants to be final" and "it is incompatible with Electrum":
None of this is true. Firstly, it *is* possible to implement both algorithm
into the client at the same time, so user will be able to recover wallet
using Electrum or bip39 mnemonic and - what is worse - you already *know*
about this solution. Still you're spreading FUD about it on IRC, on emails
behind my back and here on mailing list.
The solution for Electrum client - as we discussed two weeks ago on IRC -
is that:
a) User type down the mnemonic (created with Electrum or BIP39)
b1) Only if *all* words are presented in both dictionaries and it has valid
BIP39 checksum (which is quite rare situation itself!), the mnemonic can be
consider to be both Electrum or BIP39.
b2) In most of cases we end up here, because the most common situation is
that with given words, only Electrum *or* BIP39 seed can be recovered.
----
c) Consider the mnemonic as Electrum. Create first few addresses and do a
lookup. If there are transactions in address history, this is Electrum
mnemonic.
d) If there were no used address in c), build seed using BIP39 and do the
same lookup. If there's history, this is BIP39 mnemonic.
e) If there are no history on both algorithm, then pick prefered one for
given client (it should not hurt which one, because first use of given
mnemonic will "freeze" given algorithm for next time of mnemonic recovery).
Well, because only Electrum uses some mnemonic algorithm to this date, such
decision tree need to be implemented only in Electrum. You cannot tell that
"it is too complicated" or "ambiguous", because you're using the same
algorithm of deciding between Electrum deterministic / BIP32.
I must admit that I'm quite annoyed of such discussion, 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/d8ba8bd2/attachment.html>

2023-06-07 17:07:59

- reply

📅 Original date posted:2013-10-24
📝 Original message:On Thu, Oct 24, 2013 at 7:29 PM, <thomasV1 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131024/05ebacd9/attachment.html>

2023-06-07 17:07:06

- reply

📅 Original date posted:2013-09-30
📝 Original message:Hi,
during several weeks I'm observing more and more frequent issues with
bitcoind. The problem is that bitcoind stops responding to RPC calls, but
there's no other suspicious activity in bitcoind log, CPU usage is low,
disk I/O is standard etc.
I observed this problem with version 0.8.2, but it is still happening with
0.8.5. Originally this happen just one or twice per day. Today my
monitoring scripts restarted bitcoind more than 30x, which sounds alarming.
This happen on various backends, so it isn't a problem of one specific
node. Is there anybody else who's observing similar problem?
Thanks,
slush
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130930/bcb9dc1b/attachment.html>

2023-06-07 17:06:46

- reply

📅 Original date posted:2013-09-10
📝 Original message: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 <gmaxwell at gmail.com> wrote:
> On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
> <matthewmitchell at 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.
>

2023-06-07 17:06:44

- reply

📅 Original date posted:2013-09-10
📝 Original message: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 <matthewmitchell at godofgod.co.uk> wrote:
> I like this, though maybe sometimes you'll get rude word combinations come
> out.
>
> Matthew

2023-06-07 17:06:43

- reply

📅 Original date posted:2013-09-10
📝 Original message:Hi all,
we just finalized the draft and reference implementation of BIP39. Regards
to rules in BIP0001 we're asking for comments.
The aim of the proposal is to standardize algorithm across various clients
and fix some design problems of existing (but not yet standardized)
Electrum mnemonic 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130910/98b6c6cc/attachment.html>

2023-06-07 17:05:58

- reply

📅 Original date posted:2013-08-15
📝 Original message:On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn <mike at plan99.net> wrote:
> On Thu, Aug 15, 2013 at 10:22 AM, slush <slush at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130815/3faadd9b/attachment.html>

2023-06-07 13:38:42

- reply

📅 Original date posted:2013-03-13
📝 Original message: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 <mark at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130313/b9c1b3c2/attachment.html>

2023-06-07 12:46:43

- reply

📅 Original date posted:2012-12-04
📝 Original message: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 <jim618 at 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 ! :-)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121204/833e9f8b/attachment.html>

2023-06-07 12:38:13

- reply

📅 Original date posted:2012-11-06
📝 Original message:On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr <luke at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20121106/2d9a1a30/attachment.html>

2023-06-07 12:20:36

- reply

📅 Original date posted:2012-07-09
📝 Original message: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 <timon.elviejo at gmail.com> wrote:
> Should the web promote them?
> After all, you can't know what they do. What if one of them contains a
> back door or something?

2023-06-07 05:07:17

- reply

📅 Original date posted:2012-02-14
📝 Original message: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 <gavinandresen at gmail.com>wrote:
> 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 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/20120214/9dcf5699/attachment.html>

2023-06-07 05:03:12

- reply

📅 Original date posted:2012-02-01
📝 Original message: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 <gronager at ceptacle.com>wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> to share with you!
>
> === libcoin is a crypto currency library based on the bitcoin/bitcoin
> "Satoshi" client. ===
>
> Copenhagen, Denmark - 1st February 2012 Ceptacle announces the release of
> the first version of the crypto currency library "libcoin" based on the
> bitcoin/bitcoin "Satoshi" client.
>
> libcoin also maintains a version of bitcoind that is a 100% compatible
> drop-in replacement of the bitcoin/bitcoind client: You can use it on the
> same computer on the same files and you can call it with the same scripts.
> And you can easily extend it without touching the basic bitcoin source
> files.
>
> The libcoin/bitcoind client downloads the entire block chain 3.5 times
> faster than the bitcoin/bitcoind client. This is less than 90 minutes on a
> modern laptop!
>
> In libcoin, the Satoshi client code has been completely refactored,
> properly encapsulating classes, removing all globals, moving from threads
> and mutexes to a pure asynchronous approach. Functionalities have been
> divided into logical units and libraries, minimizing dependencies for e.g.
> thin clients.
>
> libcoin is chain agnostic, all chain (bitcoin, testnet, namecoin,
> litecoin, ...) specific settings are maintained from a single class (Chain)
> and hence experiments with chain settings, mining, security and digital
> currencies for research and educational purposes are easily accessible. See
> the ponzicoin example for how you define your own chain.
>
> The build system of libcoin is based on CMake and supports builds of
> static and dynamic libraries on Linux, Mac OS X, and Windows.
>
> The libcoin license is LGPL v. 3. This mean that you can use it in open
> source as well as in commercial projects, but improvements should go back
> into the libcoin library.
>
> ======
>
> Read more on libcoin on: http://github.com/ceptacle/libcoin/wiki
>
> Join libcoin on twitter: http://twitter.com/libcoin
>
> Download "libcoin Satoshi release":
> http://github.com/ceptacle/libcoin/zipball/v0.4.0.1
>
> Best regards,
>
> Michael Gronager, PhD
> Director, Ceptacle
> Jens Juels Gade 33
> 2100 Copenhagen E
> Mobile: +45 31 45 14 01
> E-mail: gronager at ceptacle.com
> Web: http://www.ceptacle.com/
>
>
>
> ------------------------------------------------------------------------------
> 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 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/20120201/da513105/attachment.html>

2023-06-07 05:01:31

- reply

📅 Original date posted:2012-01-31
📝 Original message:Hi Amir,
> All the HTML, URI and everything uses decimal numbers alone. I see no
reason for breaking with tradition.
excuse me if it was already discussed, but maybe using satoshis instead of
decimal bitcoin would be better choice? We all know about pains with proper
handling decimal numbers 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 <zgenjix at yahoo.com> wrote:
> BIP 20 really has no support among implementations such as Bitcoin-Qt,
> Electrum, MultiBit or Bitcoin-JS. As the most active and visible user
> facing GUI projects (all with some form of URI Scheme), their opinion
> carries the most weight. To a lesser degree Bitcoin-Qt has the large
> majority of users too (although that's a line of reasoning I'd discourage).
>
> Normally we should probably Reject BIP 21 and re-submit a new standard
> (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20
> sans some sections b) it is still a draft, probably the best thing here is
> if you all agree on something to run it by BlueMatt and then we'll make it
> the new BIP 21.
>
> I can see a consensus forming on most parts. Just the send private key is
> contentious, and there's the topic of adding a time to expire field for
> merchants (this is a very good idea IMO).
>
> Also BIP 20 is problematic because it is incompatible with about every
> standard on the web. All the HTML, URI and everything uses decimal numbers
> alone. I see no reason for breaking with tradition. Note that everytime I
> have to write Color or Vectorize (as a British speaker) in my code, I die a
> little inside. But it's convention and American English = International
> English. Also it would be cool if all code used a *real* international
> language (like Esperanto) but the world ain't perfect! We live in a
> decimal-counting English-speaking Windows-using God-worshipping world!
>
> (no offense to decimal-counting English-speaking Windows-using
> God-worshipping world- I do half those things too :)
>
>
> ------------------------------------------------------------------------------
> 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 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/20120131/1da41631/attachment.html>

2023-06-07 04:56:17

- reply

📅 Original date posted:2012-01-16
📝 Original message:> 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 <etotheipi at 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 <jgarzik at exmulti.com> <jgarzik at exmulti.com>
> To: Amir Taaki <zgenjix at yahoo.com> <zgenjix at yahoo.com>
> Cc: "bitcoin-development at lists.sourceforge.net" <bitcoin-development at lists.sourceforge.net> <bitcoin-development at lists.sourceforge.net> <bitcoin-development at 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 <zgenjix at yahoo.com> <zgenjix at 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 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/20120117/61e06bb7/attachment.html>

2023-06-07 04:47:51

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Slush supports the KISS attitude of using standard URLs, opposed to over-engineering aliases, and sees no serious issue with URL proposals.
📝 Original message:OK, I'm ignoring your sarcastic style, I just wanted to support the URL
idea, which is KISS attitude, in the oposite of everything else proposed
here. I'm really affraid of over-engineering the aliases, which will make
it hard to implement in clients. Somebody noticed account implementation in
standard client - yes, it's good example of fail.
I still don't see any serious issue with the URL proposals. And sipa's idea
of posting back the transaction ID is also interesting, prividing yet
another flexibility in implementation and possible usage.
Btw, Rick, feel 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, Rick Wesson
<rick at support-intelligence.com>wrote:
> On Thu, Dec 15, 2011 at 4:07 PM, slush <slush at centrum.cz> wrote:
> > 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.
>
> wow, really. Maybe you could review some RFCs, there are thousands of
> examples where some really smart engineers chose the exact opposite
> path which you propose below.
>
> -rick
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/97352afb/attachment.html>

2023-06-07 04:47:44

- reply

📅 Original date posted:2011-12-15
🗒️ Summary of this message: Slush supports using standard URLs for Bitcoin addresses, finding them easy to implement and understand, and flexible for personal or business use.
📝 Original message: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 <andyparkins at 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.
>
> > genjix at 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
>
> genjix at 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 "genjix at 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
> genjix at 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
> andyparkins at 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 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/20111216/c1446aa4/attachment.html>

2023-06-07 04:44:49

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: Slush suggests that there is no need for a payload format like JSON or XML, and all that is required is an address in response.
📝 Original message:In my opinion, there's not necessary any payload format (json, xml,
multipart). In keeping stuff KISS, everything we need is just an address in
response + potentially some stuff like HTTP redirects (for providing
additional compatibility for proposal of bitcoin URIs with "amount",
"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 <jordanmack at parhelic.com>wrote:
> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JSON is a stand out
> option. Using HTTP for the data interchange will make things difficult
> for a lot of developers if multipart responses are used. JSON will be
> greeted with open arms.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/33ea8eb3/attachment.html>

2023-06-07 04:44:42

- reply

📅 Original date posted:2011-12-19
🗒️ Summary of this message: HTTP standard is sufficient, and bloating payload with JSON/XML is unnecessary. The argument for using JSON in server RPC is flawed.
📝 Original message:I agree with Luke that HTTP standard has everything necessary and bloating
payload with json/xml is not necessary.
Btw that argument "we have json in client already" seems pretty wrong,
because json in server rpc solves another problem (and solve it in wrong
way, because of data type issues, but it's another story).
slush
On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack <jordanmack at parhelic.com>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 data can be base64 encoded,
> although I'm not sure why you would need to send back binary in an alias
> response.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111219/fabde08e/attachment.html>

2023-06-07 04:44:13

- reply

📅 Original date posted:2011-12-18
🗒️ Summary of this message: The author expresses concern about the lack of an easy and secure solution for using aliases in Bitcoin transactions, and suggests using SSL communication authenticated with a bitcoin address as a potential solution.
📝 Original message: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.wuille at gmail.com>wrote:
> 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 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/20111219/d492945b/attachment.html>

2023-06-07 04:43:35

- reply

📅 Original date posted:2011-12-16
🗒️ Summary of this message: Slush believes using Namecoin for aliases is over-engineering and prefers a simpler solution like HTTPS lookup for addresses.
📝 Original message:Khalahan, honestly, using namecoin for aliases is (for me) clean example of
over-engineering. I mean - it will definitely work if implemented properly.
I played with a namecoin a bit (as my pool was the first 'big' pool
supporting merged mining), but I think there's really long way to provide
such alias system in namecoin and *cleanly integrate it with bitcoin*.
Don't forget that people who want to do lookup need to maintain also
namecoin blockchain with their bitcoin client. It goes against my instinct
of keeping stuff easy.
For example, yesterday I implemented HTTPS lookup for addresses into my
fork of Electrum client. I did it in 15 minutes, it works as expected, it
does the job and the implementation is really transparent, becuase
implementation is 20 lines of code. There's no magic transformation, no
forced "?handle=" parameters or whatever. And I don't care if somebody
provide URL
https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True
And everybody can do the same in their clients, in their merchant
solutions, websites or whatever. Everybody can do HTTPS lookup. But try to
explain DNS, Namecoin, IIBAN, email aliases to other programmers...
Those IIBAN - well, why not. At least I see the potential in PR. So far I
understand it as some teoretic concept which is not supported by anything
else right now. Give it few years until it matures and then add IIBAN alias
to Bitcoin client too.
Maybe I'm repeating myself already, but the way to go is to make aliases as
easy as possible, so everybody can implement it in their own solution and
thus practially remove the need of using standard bitcoin addresses for
normal users. Using some superior technology, which is hard to implement or
even understand 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 <khal at dot-bit.org> wrote:
> **
> Namecoin is a peer-to-peer generic name/value datastore system.
> Don't forget it's not limited to .bit usage ! So, directly mapping things
> to .bit url would not be the optimal way of using namecoin.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/d08d98b2/attachment.html>