Bitcoin Forum
September 18, 2021, 08:02:08 PM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
1  Bitcoin / Electrum / Re: Unexpected magic characters on: December 03, 2017, 11:40:35 PM
The following workaround seems to be giving me some success:

If you get the "unexpected magic characters" error, make sure you have a non-hardware wallet window open in Electrum (create a dummy wallet for this purpose if you don't already have one) and then close your hardware wallet window (or all your hardware wallet windows if you have multiple open - although IME having multiple HW wallets open in Electrum tends not to work well).  Then re-open the offending hardware wallet using Electrum's  "Open" menu.  This seems to work for me quite well (on OS X).  YMMV...

(EDITED because the above seems to work better than my first suggestion.  For the record, my previous suggestion was: "It seems to be that the "unexpected magic characters" message is, at least sometimes, not fatal.  Try doing something that requires authentication with the Trezor (such as signing a message) and Electrum might recover....")
2  Bitcoin / Armory / Re: Armory 0.96.1 started crashing suddenly (a macOS-specific question) on: August 23, 2017, 10:20:25 PM
I've been seeing the same since updateing my Mac from 10.11.4 to 10.12.4.

I'm guessing it's an issue with some recent update to OS X.
3  Bitcoin / Armory / Re: The new Armory website on: September 04, 2016, 11:54:00 AM
Maybe also try getting listed on bitcoin.com?
I'll try, but I don't like them. The wallet page is a mess to use.

Yeah, it's a bit broken, isn't it.  It's been like that since forever - don't know why they haven't fixed it yet.  EDIT: I've reported it to them.  We'll see if it  does any good.

Still, bitcoin.org and bitcoin.com are on opposite sides of the block size debate.  Since Armory is blocksize-agnostic (AFAIK) it would be good to aim for a listing in both places.
4  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: September 01, 2016, 10:57:39 PM
Short term price speculation? I'm mixed about getting in... was sure it was gonna drop more but now not so much


25% is pretty impressive, and if I was buying something at the DNM I'd feel safer using xmr. The people who use DNMs have no problem acquiring xmr

What about the problem of some people about the "view key" feature. They said that a court order could make you show your transactions in the clear thru view key. Is this true? Why is that feature even there? It might become Monero's weakness.

Well, assuming that's true in some jurisdiction then if, hypothetically, Monero had been designed without a view key - so that the only way you could view your transactions was with your private key - then in that scenario a court could almost certainly just order you to release the private key instead.  Better to give the court just the ability to view, rather than the ability to view and spend.

It's much the same as (one of) the more general arguments for not using the same keys for encrypting and signing messages.  In many jurisdictions courts can demand keys to decrypt your messages, but there's rarely if ever a valid reason for them to demand to be able to forge your signature on messages.  So again, it's useful to be able to give them just the key they need, rather than the only way of complying with the order being to give them far more than they need.

roy
5  Bitcoin / Armory / Re: The new Armory website on: August 31, 2016, 08:46:02 PM
Maybe also try getting listed on bitcoin.com?
6  Bitcoin / Armory / Re: The new Armory website on: August 30, 2016, 08:42:22 PM
I thought Armory was pretty much dead as no one talks about it anymore. If you guys are looking for any translators for both Arabic and French language then I'm available to help. (using transifex would be great)

There definitely is a lack of appreciation outside of this forum that open-source Armory is still going strong.  And also a lack of knowledge outside this forum as to who goatpig is and why they should trust the new releases.

I don't really know what we can do to help get the word out, though.
7  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: August 30, 2016, 08:02:20 PM
I wasn't aware you could get actual legit medications on DNMs. I may have to look into doing that.

It gets harder and harder every day to buy low-cost prescription medications with credit cards.  For payments that actually work, there's Monero.

That sounds like the voiceover to a commercial. It's true, though. The credit card companies have been cracking down on online pharmacies hard recently.
Little do they realize, they may be digging their own graves.

Unfortunately those who buy from illegal online pharmacies are often digging their own graves, too - that's part of the reason governments are cracking down on them.  The incidence of customers receiving medication that is at best ineffective and at worst actively dangerous seems to be quite high.
8  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: August 22, 2016, 08:25:59 PM
Concern for that common seed attack is the reason eds adds entropy correct?

Are you talking about the issue with repeated k-values in ECDSA signatures?  In principle EdDSA (as used with Ed25519) has the same problem.  However, DJB's reference implementation uses deterministic k-values (as, I suspect, do all implementations of Ed25519) to avoid the need for a crytographically strong random number generator during signing (you still need a cryptographically strong random number generator for key generation, though!)

This solution isn't unique to EdDSA, though - deterministic k-values can and are used with conventional ECDSA, too.  RFC6979 defines one such  implemention, and I believe that some Bitcoin wallets actually use this.  The difference is that ECDSA (like DSA) is conventially defined and implemented with random k-values (like DSA) meaning that most implementations have an unnecessary vulnerability in the event of a poorly-seeded PRNG.
9  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: August 21, 2016, 11:21:22 AM
Also, more generally than just choice of curve, the CryptoNote coins (of which Monero is one) are rare amongst cryptocurrencies in sharing very little of the cryptographic design of Bitcoin.  So in the event that a flaw is found in Bitcoin's cryptographic design, there's a reasonable chance it might not affect Monero (or vice versa).

The one obvious advantage that Bitcoin does currently have over CryptoNote is that its design (which has remained fundamentally unchanged since it's initial launch) has been very widely studied over the years since then.  Generally this kind of widespread review is the only way to gain assurance that there are no flaws in a cryptographic protocol, and Monero has inevitably had fewer cryptographic eyes on it.

Of course, in the very near future Bitcoin is likely to deploy segwit.  Although segwit doesn't change the underlying cryptography, a significant change to cryptographic protocol always carries a risk of unintended consequences - so it becomes harder to argue that Bitcoin, in its post-segwit future form - will have had the same number of eyes on it.
10  Alternate cryptocurrencies / Speculation (Altcoins) / Re: [XMR] Monero Speculation on: August 21, 2016, 11:04:52 AM
Quote
Popularity

Curve25519 was first released by Daniel J. Bernstein in 2005,[7] but interest increased considerably after 2013 when it was discovered that the NSA had implemented a backdoor into Dual EC DRBG. While not directly related,[8] suspicious aspects of the NIST's P curve constants[9] led to concerns[10] that the NSA had chosen values that gave them an advantage in factoring[11] public keys.[12]

    I no longer trust the constants. I believe the NSA has manipulated them through their relationships with industry
     Bruce Schneier, The NSA Is Breaking Most Encryption on the Internet (2013)

Since then, Curve25519 has become the de facto alternative to P-256, and is used in a wide variety of applications.[13] In 2014 OpenSSH[14] defaults to Curve25519-based ECDH.

https://en.wikipedia.org/wiki/Curve25519

I agree that Wikipedia article isn't as clear as it could be - in that the context of the Bruce Schneier quote isn't particularly clear to readers not familliar with the history of the curves being discussed here.  But I assure you that Bruce was not talking about Curve25519 there.

The reason for the inclusion of that particular quote in the article is to explain why Curve25519 has become popular in recent years:  there are concerns about the choice of constants in other curves, which has resulted in many more people using Curve25519 precisely because there are no such concerns with Curve25519.

Curve25519 is generally considered to be safe.  That said, there are those who worry (Bruce Schneier included) that the NSA may have made advances in the cryptanalysis of ECC in general - but if that's the case then any attacks might affect all curves - or at least, we have no way of knowing which curves are vulnerable.  If that were to be the case, it would be a concern for pretty much all cyrptocurrencies, though - potentially necessitating a move to larger keys (depending on how bad the attack is).

Actually, using a different curve to the one used by Bitcoin and most other coins is a good thing because it gives the market an opportunity to hedge the risk by holding coins that use different curves.  If an attack on ECC is found (by the NSA or someone else) it's quite possible (although by no means a given) that the attack might work better against some curves than others - although there's no real way to know which curves are safer in advance of the attack being found.

EDIT: Actually, looks like I was wrong - Monero uses Ed25519 and EdDSA (not Curve25519 and ECDSA).  So it shares even less crypto with most other coins that I had thought.
11  Bitcoin / Armory / Re: Moving forward with Armory on: February 04, 2016, 11:56:42 PM
I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer.

I thought it was proper to indicate where the code starts to diverge, by hash. There is no clearer way to designate a point in the development time line where all code is ATI's property before and anything after is a mix and match. I've removed it from the license.

I don't think it's bad to indicate where they diverge (but it would be more readable to reference the commit by tag, now you've imported them).

My main concern (sorry if I didn't read it carefully enough and misunderstood) was that your original approach seemed to me to be saying that there would be files in your distro that had portions under one license but subsequent changes under another.  I think attempting to apply licenses to an individual file at the commit level is problematic - hence my advice to just accept that modified files are derivative works and will have to be licensed in their entirety under the GNU Affero GPL.

It's late now, I'll try and review your updates soon.

EDIT: Or put another way -  where the development diverges is useful and interesting information, and there's no reason not to include that information.  But I wouldn't personally word the license in such a way that it depends on this; such commentary should be purely informational and clearly not part of the license terms.
12  Bitcoin / Armory / Re: Moving forward with Armory on: February 04, 2016, 09:14:02 PM
Also to add.  99% of this is about avoiding legal disputes in the first place.  Whether or not you intend to follow my advice, you'd be well advised to run whatever approach you do settle on by any contacts you have at ATI for their opinion.  It ultimately matters not who would win in court, unless you have the inclination and resources to see a lawsuit.  What matters is whether you're doing something that might cause ATI to feel aggrieved and which might incline them to take legal action.

EDIT: But don't worry too much if ATI is effectively defunct and you can't get a formal opinion.  An informal opinion is still better than nothing (particularly given unspecified legal complications with the IP) but I would say it's by no means essential, and I wouldn't worry unduly.
13  Bitcoin / Armory / Re: Moving forward with Armory on: February 04, 2016, 08:51:25 PM
And to follow up, of course for an easy life, you could just release everything under the GNU Affero GPL.  But I applaud your desire to release under a permissive license.  It will only really benefit anyone, though, where there are significant amounts of self-contained new permissively licensed (category 3) code that would be useful to some other project that for what ever reason couldn't (or didn't want to) use any ATI-derived code.

14  Bitcoin / Armory / Re: Moving forward with Armory on: February 04, 2016, 08:09:38 PM
What I am mostly concerned about is keeping this whole forking "Kosher": I don't want the new code that will coexist and be intertwined with the old code to somehow fall under the umbrella of the preexisting IP contention because I messed up on my due diligences with license language and what not.

CAUTION: I AM NOT A LAWYER.  But I think I can probably steer you in broadly the right direction nonetheless.

You own the copyright to the new code that you write on your own dime.  Nothing can restrict your right to do what you like with your code, short of selling or otherwise assigning the copyright to someone else.  The license you release your code under is your grant of a license to other people; it tells other people what they are allowed to do with your code.  But you are always free to do what you like with your code - including relicense it under different terms - since you own it.

(EDIT: rewritten this para)  The things you have to worry about are that you don't end up using code that ATI owns contrary to any license grant.  And secondly that you don't end up releasing a product that it is effectively impossible for anyone to run without using code that ATI owns contrary to any license grant.  At the moment, the only license grant for the ATI-owned code is the GNU Affero GPL it was publicly released under, but of course you're always free to try to negotiate some more permissive license grant with ATI.

I'm very dubious of your plan to manage copyright at the level of commits - i.e. one copyright and license up to a particular commit, and another for subsequent commits.  This is very unconventional and sounds like a recipe for legal confusion.  You can't meaningfully pick apart the commits to a single file.   Don't try to do this without advice from a lawyer. 0.93.3 files that you modify should instead be treated as derivative works, IMHO.  The way I'd proceed is as follows.

The way I see it, you have three types of files.

1. Files from 0.93.3 which you haven't modified.  Keep the copyright notice and license unchanged on these files.  These files are owned and licensed by ATI.  Obviously over time there will be fewer of these; that's fine.

2. Files from 0.93.3 that you have modified.  These files are derivative works of ATI's work, and both you and ATI have copyright claims on them.  Keep these files under the GNU Affero GPL, but update the copyright notice to include both your copyright claim and ATI's.  You can't relicense these derivative works except in accordance with ATI's license grant.  Fortunately the GNU Affero GPL allows you to create derivative works provided they are licensed on the same terms.

3. New files that are entirely your own work, on your own dime.  You own the copyright on these files, so you are technically free to release these under any other license you choose - but if this license you choose were incompatible with the GNU Affero GPL then it may be impossible for anyone to legally comply with all the licenses.  Any license that is compatible with the GNU Affero GPL is fine here, so a permissive license such as the MIT license should be absolutely fine.  These new files should contain just your copyright notice and the relevant license (and no reference to ATI).

Your LICENSE file should then simply indicate that portions are copyright ATI and portions are copyright you, and that furthermore portions are licensed under the GNU Affero GPL and portions are licensed under the MIT license, and include the text of both licenses for reference.  It should instruct people to refer to individual source files to find out the copyright and license that applies to those files.  EDIT: I'd rename the existing LICENSE file to LICENSE-ATI or LICENSE-0.93.3 or some such, and leave it unchanged except for a some added text at the beginning saying this was the license under which ATI released 0.93.3.  I'd then reference the LICENSE-ATI file from your new LICENSE file, too, and indicate that this was the license under which the ATI-owned code was orignally released.  This is useful for reference, and it also avoids breaking the reference in the ATI copyright messages to see the LICENSE file.

Obviously, you want to aim to modularise things in such a way as to maximise the number of files that fall into category 3 - but of course you have to be careful when refactoring not to accidentally move pieces of ATI-derived code into your category 3 files - or at least, if you do, you should recategorise those files as category 2.

I'm pretty sure what I describe above is safe, and is the most sensible way to proceed, but once again IANAL.  Happy  to answer questions, though, if any of the above is unclear.  EDIT: And of course happy to review and comment on your updated license/copyright notices.

Regards,

roy

EDIT: Significant edits to the above - you may want to reread.
EDIT: Further edits to the advice on LICENSE files.
15  Bitcoin / Armory / Re: Moving forward with Armory on: February 03, 2016, 11:14:13 PM
Armory only sets up an RPC connection to Core when running the auto bitcoind management. I'd prefer a solution that covers ever case.

I believe that 0.12 also includes some code that generates a temporary random RPC password if none is configured - and writes it to a file - to make it easier for local clients to use the RPC interface without requiring prior configuration.

EDIT: Don't know if this functionality is enabled in GUI mode, though, or only for bitcoind.

P.S. Out of curiosity, what does Armory currently use the RPC connection for?  Just wondering what I'm missing out on, given I don't have Armory managing my Core instance.
16  Bitcoin / Armory / Re: Moving forward with Armory on: February 03, 2016, 10:12:17 PM
For both you would need the C++ side to feed you some sort of RBF flag for each UTXOs.

Core 0.12 has an RPC call to tell you whether a tx opts in to RBF (which AIUI also checks whether an unconfirmed parent tx opts in).

EDIT: Although perhaps it's only useable if the tx pays to an address in the Core wallet - I haven't looked at what it does so I don't know.

EDIT: See https://github.com/bitcoin/bitcoin/pull/7222
17  Bitcoin / Armory / Re: Moving forward with Armory on: February 03, 2016, 08:36:31 PM
First off, many thanks to both @etotheipi and @goatpig for all you've done, and continue to do, for the Bitcoin community.

Two quick questions for goatpig:

1. Any chance of setting up a download location for the open source project, with 0.93.3 builds?  This will at least make Armory useable again to a wider community.

2. Will your open source project continue to use the Armory name, or is that a trademark of ATI?
18  Bitcoin / Armory / Re: Armory 0.93.3 with BIP62 compliance on: December 03, 2015, 09:54:22 PM
Armory 0.93.3 with BIP62 Released

Download links below, but as always, please use the secure downloader within Armory under "Help"-->"Update Software" or on the Announcements tab on the main screen.

More out of curiosity than anything else, but is the secure downloader actually working at the moment?  For me, it complains that it hasn't seen an update in months, and won't show me anything recent.  But I self-built, so maybe something broke.
19  Bitcoin / Armory / Re: Armory 0.93.3 with BIP62 compliance on: November 30, 2015, 08:08:10 PM
Is 0.93.3 going to be put up on the website?  Currently the downloads link still seems to point to 0.93.2.

roy
20  Bitcoin / Armory / Re: Will the free open source Armory wallet continue to be developed going forward? on: November 16, 2015, 07:30:31 PM
There are ways to distribute a closed source that's pseudo community reviewed: get a few key community members to sign a NDA, deliver them the code, reproducibly build the software and have every member sign the hash. This scenario is suboptimal on both ends though. Users don't want sign a NDA and the business doesn't want to expose the source to that many individuals, NDA or not.

Bitcoin is an open source market. You have no business developing core functionalities like wallets if you're not prepared to reveal the source and be scrutinized. Closed source and DRMs are old models, mostly created and maintained by the entertainment industry (for poor results). Trying to force that on the Bitcoin market is just a recipe for failure. The revenue model should adapt to the environment, the opposite approach is silly at best.

I'm no business man. I think the crowd funding model is a reasonable way forward for any long term FOSS project, but I can't fathom what a sustained revenue model would be like. I do think we do not yet have enough applications on top of Bitcoin to design such model. It's very possible some top layer app will "rule them all" and bring closure to the business cycle. Maybe Armory coupled with a hardware signer and a high level of customization could become the stack of choice to run Lightning payment channels in the future. Maybe the future of streaming will be proof of payments on some sidechain and decentralized distribution on top of namecoin. Time will tell.

One thing is certain, Bitcoin's business cycle is very long, and some people jumping into this market are too quick to dismiss this parameter.

A product can be source-available, without being under a FOSS license.  This allows the community to review (without the need for an NDA) but only to run under a restrictive license (or possibly not legally to run at all without paying a fee).  Of course, not everyone will respect the license, but you have recourse to the courts if someone builds a business on your software illegally.  Recourse to the courts does rely on you finding out that the business is illegally using Armory, of course.  It's not perfect, but broadly speaking big financial institutions are likely to care about compliance.

Another compromise would be a closed source online component with an open source offline signer.  That's not perfect, either, but at least it gives a high degree of assurance for cold storage applications - which I presume are the main draw of Armory.  It's still far from ideal, though, since there's a very real risk that the government could require ATI to put a backdoor into the code.  Even though I'm not doing anything that would make me a target for government action, the very presence of such a backdoor would still increase the attack surface of my online system.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!