Bitcoin Forum
September 24, 2022, 11:09:11 PM *
News: Latest Bitcoin Core release: 23.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 »
1  Local / Trading und Spekulation / Re: Bitcoin Trade-Manager: Spreadsheet listet (Ver)Käufe und berechnet G&V und mehr on: May 02, 2017, 10:57:04 PM
Hallo Michael,
weiss nicht, ob du das überhaupt noch liest. Mt Gox gibts schon lange nicht mehr und btc für wahnwitzige 9€ Shocked. Ich hoffe, du hast die 479 btc noch Grin
Wollte nur Danke sagen. Genau so ein Tool habe ich gesucht. Mich würde ja fast mal interessieren, wie andere das machen?! Irgendwie habe ich noch nichts besseres gefunden. Arbeitest du auch noch damit? Hast du eine Möglichkeit für andere Cryptos eingebaut? Du wirst ja sicherlich auch mittlerweile mehr als btcs haben.

Beste Grüße

Hallo,

danke für die Rückmeldung. Ich war in letzter Zeit nicht mehr aktiv hier im Forum, verfolge Bitcoin & Co aber weiterhin. Es hat sich ja richtig viel getan die letzten Jahre, und was zur Zeit gerade abgeht liefert ja Stoff für die Geschichtsbücher - da wird gelogen und intrigiert dass es nur so kracht - Kämpfe mit allen Mitteln - ein echter Live-Wirtschaftskrimi, was einem da geboten wird...

Es freut mich, dass dir das Tool nützt! Ehrlich gesagt, ich weiß auch nicht, wie man das sonst machen soll, und genau deshalb hab ich das Tool ja geschrieben, und es wundert mich, dass hier nicht die großen Massen jubelnd Luftsprünge machen :-P

Wo du das mit den "479 EUR" her hast, ist mir jetzt allerdings ein Rätsel - die Zahlen im Sceenshot oben sind jedenfalls alles nur Beispielzahlen für Demo-Zwecke - darauf hatte ich auch hingewiesen :-)    ...oder hatte ich an anderer Stelle mal irgendwas erwähnt?! Jedenfalls hab ich Mitte 2015 richtig viel verkauft - sehr nahe am Tiefpunkt bei ca. 200 USD - bin halt kein Trading-Talent... :-(

Michael
2  Bitcoin / Bitcoin Discussion / Re: Release - Open source software - replacing hardware wallets with image { on: July 23, 2016, 11:07:39 PM
This kind of steganography-- hiding data in the least significant bits of images-- is _very_ easily detected by statistical methods, and there are many papers and tools (stegdetect, for jpeg as an example) to do so.

post #25's method should be safe.
3  Bitcoin / Bitcoin Discussion / Re: Release - Open source software - replacing hardware wallets with image { on: July 23, 2016, 06:55:14 PM
I am not an expect in steganography but from common sense I am amusing that there is a way bigger risk that if you print it and save it physically like a paper wallet, it's way easier for the key to corrupt and not be able to read it back because of way too many colors and stuff on the game. Like the image can deteriorate physically (from the paper rotting over time and so on) and then the device trying to scan it will have a hard time guessing the key.

On the contrary with a classic normal QR code it's way simpler there fore easier for the device to scan it.


you are not meant to print and rescan the image with the method of this thread. This won't work.
4  Bitcoin / Bitcoin Discussion / Re: Release - Open source software - replacing hardware wallets with image { on: July 23, 2016, 06:19:01 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

  • Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

  • it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
  • it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

  • Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
  • Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?

Great questions

A.1 the software relies on decryption errors. At the moment it should break or throw an error if the AES library can't decrypt the data. It doesn't stored bitcoin keys, it stores AES encrypted data, which happens to contain bitcoin keys. you can read more about this steganography library on this PDF

A.2 The output PNG image should be less than the original. I have an original PNG image which is 14.8MB and an output which is 9.36MB

A.3 At the moment the SW only supports individual keys since this is the first-iteration / release of it. You can make request by following the below quote

Quote
You can make appeals to modify, upgrade, or add any functionality on this thread As long as you have any research which proofs your upgrade/addition is superior/adequate


So A1 reads: No, not every image-password combination is a priv key, and you can tell from wrong password that the password is wrong without checking the blockchain.

About A2: This is strange. How can it happen? And does it also happen if the original image is a computer screen shot that typically contains many successive pixels of identical colour?
5  Bitcoin / Bitcoin Discussion / Re: Release - Open source software - replacing hardware wallets with image { on: July 23, 2016, 06:10:19 PM
In fact, *every* steganographic method can be broken with currently available stegoanalitic methods(which are typically statistical methods).  The only question is whether there is enough data, but practical amounts are sufficient (no astronomical figures like in crypto).

I think it depends how you do it.

Imagine you have your "original" image that you want to modify to include your key via steganography. If your original image satisfies certain characteristics, I am sure you couldn't tell if the post-processed image contains steganography or not.

Here is how I construct my "original" image:

* take a camera picture.

* add noise on it and save as *.png (lossless format)

The noise addition follows this algorithm: For each pixel take each original 8bit rgb value and replace the LSB (rightmost least significant bit) by a random 0/1.

And here's how I hide my 256 bit bitcoin private key (pk)  inside this image:

* calculate y = "pk" XOR "sha256(myPassword)"

where XOR is a bit-wise operation of 256 bits.

y is a 256 bit sequence that looks absolutely random, also from statistical analysis point of view.

* I replace the first 256 "noise LSBs" of the image by "y".

Done!
6  Bitcoin / Bitcoin Discussion / Re: Release - Open source software - replacing hardware wallets with image { on: July 23, 2016, 05:41:46 PM
Very nice indeed. this sw should be standard since years. I am surprised it comes so late and highly welcome it!

A few questions:

  • Q.1: does the sw detect that the image contains a bitcoin key when entering the correct password even offline (e.g. by some header info or checksum after correct password entering), or is every image-password-combination a valid key? --> the latter would be better because:

  • it would make the image even more difficult to brute-force! (you'd have to check with the blockchain each time you try a new password)
  • it would provide powerful means against the "$5-wrench-attack": you can store two (or more) keys in one image via two (or more) different passwords and load different amounts on it. should you ever get attacked with a "$5-wrench", you give away your dummy key with a small amount of btc and plausibly deny existence of another key.

  • Q.2: I understand that the privkey is stored in the 1 or 2 LSBs of each pixel's 8-bit RGB values, probably after XOR-ing with "sha1(password)"-bit-sequence or sth. like that. But this means that a *.png image would increase in size, compared to the original image, if the original *.png image contains sequences of pixels of identical colours, due to *.png's lossless compression (run lenght encoding). So the original image should preferably be an image that already contains some "noise" on the LSBs, do I understand correctly?
  • Q.3: Does the SW support only individual keys or also HD keys with 12-to-24-word mnemonics acc to BIP32/39/44?
7  Bitcoin / Development & Technical Discussion / BIP-100.5: Progressive Block Size Limit Voting with Default Growth Rate on: September 20, 2015, 06:25:45 AM
I wrote another (much simpler!) proposal for combining the best of BIP-100 and BIP-101, so I called it "BIP-100.5" for now.

I focussed on...

* Decentralization
* User adoption over time
* Technological progress over time
* The uncertainty of the two above
* Interests of the eco-system
* Interests of the miners
* Reasonability and pragmatism
* Likelihood of adoption
* Simplicity of implementation

Although I used BIP-100 as the template, there are too many changes for making it a pull request to BIP-100 I think.


Abstract
This BIP proposes to replace the fixed 1 MB block size limit with an adaptive limit that can float between 1 MB and 61 GB (temporarily 1..32 MB) based on a default growth rate and miner voting. This combines the merits of BIP-100 and BIP-101 within a new generalized mechanism. Both BIP-100 and BIP-101 can be considered special cases of this BIP, depending on the choice of hard-coded parameters.


Full description here: https://github.com/1MichaS1/BIP100dotFive

Fierce proponents of BIP-100 and BIP-101 respectively will probably not like any other proposal than "their's" - for the vast majority I am hoping it can be a reasonable compromise that can achieve wide consensus.

Illustration: Possible block size limit evolutions for certain miner majorities (for comparison the growth rates of 17.7% and 41.4% are included) - log scale:

Note: With BIP-100, the "red default" line would be at 0.0% growth (horizontal), the 80% and 90% lines would be about where the 90% lines are in above figure, and all other lines would be 0.0% (horizontal) like the red default line. With BIP-101, all lines would be collapsed to where the +41.4% line is in above figure.


The reason why in this BIP the default growth rate is not 0.0% but some moderate positive value is that the default should, at least in tendency, follow the "bathtub":

Centralization
of Bitcoin system
  .
 /|\
  |*                                                                     *
  |*                                                                     *
  | *  (a) More users                                                   * (b) Technol. progr.
  |  * ----> time                                                      *  ----> time
  |   *                                                               *
  |    *                        ----> time                           *
  |      *      Area of best Bitcoin system decentralization       *
  |        *    |<----------------------------------------->|    *  
  |             *   *   *   *   *   *   *   *   *   *   *   *
  '--------------------------------------------------------------------------->
                                                               block size limit

Left edge = centralization due to too low capacity (tx per second, congestion, users pushed off-chain).
Right edge = centralization due to too high bandwidth + storage requirements.
Both edges move to the right as time passes, this BIP's default growth tries to stay in the flat area of the bathtub.
Voting enables deviation from the default growth.

Looking forward to your opinions!
8  Bitcoin / Development & Technical Discussion / Re: [BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug on: September 06, 2015, 03:16:11 AM
I'd like to postpone the discussion about what would be the optimum percentage for activation of a new BIP that deals with BlockSizeLimit evolution, since this parameter is really not at the core of this "BIP10X". Certainly there is no god-given optimum value, and different people will have different viewpoints here. But this is a secondary discussion, which is distracting from the main topic.

I would prefer a discussion about this BIP10X proposal as such (i.e. its solution once it is operational).

Because, it intends to fix the most criticized weaknesses of BIP100 and BIP101 (criticized not only by community members, but also from my own view), therefore I think it is really worth considering and may have the potential to gain the greatest consensus.
9  Bitcoin / Development & Technical Discussion / Re: [BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug on: September 05, 2015, 03:43:21 PM
Hello erik,

thank you for reading and commenting.

Interesting proposal.  The concerns I'd have include:

- If a vote must be used to initiate the hard fork, it should be 95%.  Note that this concept only became necessary because of the XT code fork.  Otherwise, we could of just set a date in the future and asked miners to upgrade by then.  
In the presence of the many BIPs, I think a supermajority criterion is needed. I am not sure why 95% would be better than 75%. I think 75% is enough, and I think 95% might not be reachable. Of course, if a consensus could be reached and "bitcoin-core" or another project convinces everybody to use the SW, then the new BIP10X protocol could be simply activated at a given block height.

My assumption though was that we are dealing here in a somewhat competitive environment between different proposals.

Quote
- Not sure why we want miners voting every week.  
Maybe a misunderstanding. Miners don't vote "every week", they vote continuously in "every block". The 1 week relates to the intervals in which miner votes are EVALUATED and possibly adjustments on the block size limit take place. I re-phrased this in my updated version at Github, to avoid this misunderstanding in the future.

Quote
  1> Miners are unlikely to want to interact.  How would this work with ASICs?  Miners probably don't want to have to update anything on a weekly basis.  
They don't need to. This "BIP10X" proposal suggests that miner operators do not need to interact but just configure what is their voting preference in "bitcoin.conf", and then the miner will automatically cast the correct vote according to miner operator's preferences. Operator can adjust his preferences any time (no need to respect the 1-week-intervals in any way). Also note that instead of the voting strategy "vote for fixed value", miner operator can also configure via bitcoin.conf that the voting strategy should for example be "vote for average actual block size of last week times a certain self-selected factor", or miner can vote for "same block size limit as current block size limit".

Quote
 2> Why would miner voting be needed for anything other than the hard fork?  Couldn't we just have it always calculate the block size limit periodically based on history?  I see you have a notion of this.  Buy, why as a fall-back instead of the primary method?
First, I use the actual block size criterion as a "constraint", not a "fall back" method. (But maybe you understood it right and just termed it differently)

You suggest auto-adaptation of BlockSizeLimit e.g. solely based on the actual fillings of the blocks? In principle possible, but I want to introduce miner voting "institutionalized" inside the protocol, to avoid tiring "block size limit"-motivated hard fork discussions for the future, as we have it now. Because if miners can vote within the protocol, they do not need to vote for a completely new hardfork SW but can just use the voting mechanisms already present within the protocol. I also wrote it like this in the "Motivation" section of the BIP10X proposal.

Also, we see from miners' reactions today that they like a solution where they can actively vote, hence their BIP100 support is so great. And we cannot ignore this fact. But I want to propose a solution that removes the drawbacks of BIP100 (which maybe not all miner operators have completely figured out and are aware of), i.e. an improved version of BIP100 if you want, that the miners can hopefully also well agree with, hopefully even better than with BIP100 itself. One could consider BIP10X an evolution of BIP100.

Another reason against complete "auto-adaptation" without voting is that there could be natural (e.g. seasonal) periods of lesser traffic that should not necessarily promptly lead to BlockSizeLimit adaptations (decrease) too soon. I really think that voting (or the human = miner's influence) should play an important role, and the "actual block size" constraint  should only step in if the divergence between actual block size and BlockSizeLimit vote becomes too much.
10  Bitcoin / Development & Technical Discussion / Re: [BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug on: September 05, 2015, 02:35:08 AM
I now wrote it in BIP format at Github:

11  Bitcoin / Development & Technical Discussion / Re: [BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug on: September 02, 2015, 12:04:34 AM
I wrote an overview document in quite that format - now only 5 pages.

Indeed, this is a bit easier and much faster to read than the more comprehensive 37 pages.

Please find it here as PDF (v0.2):

Please judge it by the content and not by the fact that I put it on dropbox. Wink  Thanks!
12  Bitcoin / Development & Technical Discussion / [BIP10X] A New and Detailed Proposal for the Block Size Limit - published 31 Aug on: August 31, 2015, 09:03:15 AM
Hi,

after having read BIP100, 101, 102 and 103(?), after having seen many discussions, after having heard many arguments, after weighing many pros and cons, after having read study reports about the effects of congestion in the transaction queues, after thinking for myself what other solutions might exist, I made a write-up about a solution that combines and considers many ideas and concerns. I have made several iterations of improvements before releasing the first version to the public today.

Unfortunately(?), the document has become larger than planned, it has 37 pages, but for a quick read you already get an impression when reading only page 1 (abstract) and pages 7+8 (overview).

Fortunately, it is well structured and full of information. It does not only give some basic ideas but specifies the solution down to a very detailed level close to implementation. It also has a separate chapter giving the rationale for many design decisions, and it provides simulation results (incl. simulation code) to see how the method behaves in certain corner cases.

Now I hope you have the time to read and understand the paper, and I am looking forward to hearing your thoughts. I think the interested reader will find an inspiring mixture of known and new ideas, combined in a way and detailed down to a level as it has not been seen before.

[Last update 5 Sept 2015, ~15:30 CEST]: OVERVIEW DOCUMENT in BIP Format / Github:

[Last update 5 Sept 2015, ~2:00 CEST]: FULL SPECIFICATION (39 pages):

Further sources (will not be updated as frequently as Github format above, with same content as in Github repository):

[Last update 5 Sept 2015, ~2:00 CEST]: Overview Document as PDF file (5 pages):

Looking forward to hearing from you!  Smiley
Michael

PS: I have not yet tried to apply for a BIP number (but will probably do so later), that's why I put a placeholder and am calling it "BIP10X" for now.
13  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: August 02, 2015, 04:01:15 PM
I didn't really understand in what way the plausible deniability is broken in BIP39 when using same mnemonics with different optional passwords.

So let's check/proove by example to see if I got this right, to see if the plausible deniability of BIP39 is really broken:

Via "http://bip32jp.github.io/english/" and "https://dcpos.github.io/bip39/" I created the following HD wallets:

HD Wallet 1 (let's assume this is what the "Ninjas" found out):
  • Mnemonics: secret blame broken hundred bid express effort snow bike category wonder wrist
  • Optional password: <empty> (i.e. no password at all!)
The first five addresses and key pairs are:
Code:
0     1HVYYLvskm9b9BnMkFvFwNgwAEPC5pQ8pm        KxPoX3MdNA2MKdERJAdRwQpX1LdM6DuHKmUeTLTKxUFSio1n7UKV
      Pub.Key: 0341931E073869EE4DFC769D14D35A1451E80CF3B44F1BB01EAB0FC970A5E6CC6D

1     14x3Z5HV4e6VfGMpJTENkP4abyQz1HqCrN        L2kD3HXTfL7F6nkUAxwX8hWeFMx7ssbpHijYVNJFq18xyfe9ABm3
      Pub.Key: 02BF3FD42086E624FC1684F99B35CC16BD02BF1E70AEC34BD017D8A7D266D789B3

2     14X2ypUStaG8nYsWaQHTsGhXrMVkieQtjG        KwciLYshfsAzLgpd2kJjeZD3tta7Fbwevz6Heayzugmw37P4Eunh
      Pub.Key: 03F1B8473B5781940E3B1036F572A64C7E6B4718D1A33FE2DD1A0CC6292335A0D0

3     1Nn46XR98hDWaX6mqeqdcQcyBrQPDPNCrN        L4WFgLKPSoCZHLwoSZKv76hAyziCmbACLDyWgXRz9RZc19RBcJMV
      Pub.Key: 023D529949196D46AF39147AF5021ED0DA64BB2C14405F3DBE25CDF94DB8C5D86A

4     12v88JPgLJ2dMKunUySA74hvBTS47FEvHG        KyXYjjTAmu1vW1umNG4FedrBMTqJXu5G4NBdkfbcDRYNCEvLZZXB
      Pub.Key: 029C2CFD4D65D18E9C5FA8E056D66BAB80D6CF933A6E6680B8C2B6BFAC352EC3A5

HD Wallet 2 (let's assume that the "Ninjas" found this out, too):
  • Mnemonics: secret blame broken hundred bid express effort snow bike category wonder wrist (same as above)
  • Optional password: simpletestpw
The first five addresses and key pairs are:
Code:
0     1DyP6aGfaev9NBoSZwW2CotiyreoEsDfhm        L4k4mCW4nrrVDu1iVG1a7qwavKfA6w4MDLVKuxqFmabdKFKKthBg
      Pub.Key: 038D24199DFCAE21879C7849FFFCBB5D5DA16416B7B7EB88945ECF53D293238099

1     1GjB3CEDdrbeSxgFJ4DesvgzBidxg6REwv        KxHGxoMuWBFh2pq7mdeprDwYHjyi2UwDuS6vXiUdnAwHCWMmU8Ur
      Pub.Key: 03ED97088DF8B193AD74B81747CE89B21A0535344CDA6E12A3C52AA3038060C8FF

2     12K2vAaSYWMApRuq7HUNszyfuPgzkbvjjc        L5SL1akFNR59cY5Yr3VG6uXheq9sfoc1QYTQ7vS1DEGzzgaDRR2S
      Pub.Key: 02BF29E7C2BC14948E7F4ED6DA6930C80E339AFF2351939FA2A2C2C0A14452E729

3     19FxPD5VqskxYDgqoZDNkftaTZFAPhGuFC        KyJmkryHDFTWWtgR1peGscwx4oJugBcrcqKsoGtpFsNvn716gf5p
      Pub.Key: 02BBF1E25FF57155BA747389AE493ECA019D6275AF6C98459AC3F3F70543E309DB

4     1eC5dJBakJSNjZj8g4SKyyhexoZUTBPSY         L3zgDkNCpqSrVR24AFvVMJmzxna5nJZZSEQe53aYWXiwSZxJtEcd
      Pub.Key: 020D634A935814F574565EA921D711440A6AEF611E594EBD263A5EB33F45CE9149


Now let's assume that there EXISTS a third HD-Wallet with the same mnemonics but yet another, more complicated, password (>>50 quasi-random alpha-numerical characters).
The Ninjas don't know this password and the victim is denying its existence, although the first 5 keys of that HD wallet have already been used in the blockchain, such that their pub keys are published.

The question: Can the "Ninja-attackers" find out that I lied when denying the existence of that wallet?

So I am asking gmaxwell or any other "advocatus attackeris":

Which of the following sequences of 5 public keys is the one that belongs to a HD wallet generated with:
  • Mnemonics: secret blame broken hundred bid express effort snow bike category wonder wrist (same as above!)
  • Optional password: <unknown and too complicated to brute-force>

Out of the following 10 lists (A-J) below...
  • Exactly one list is generated from a BIP39 HD wallet generated with the same mnemonics as above, plus a complicated password. The question is: Which one? (out of A-J)
  • At least 3 lists are generated from other BIP39 HD Wallets with different mnemonics and with or without optional password.
  • At least 3 lists are just random independently generated "standalone" keys.

Option A:
Code:
0     1EEdcPQPM1k442qVDrP7LnUVLysAgPdJSY
      Pub.Key: 027E4B1EC307A3B80070A2E2E22657A591D17293D4DE5F29CC8F24F04430181734

1     1D7C9jQNoaHMvMgQSDpAqkBa3e7eaxgoVg
      Pub.Key: 034C75E5BE62DC4FEE402809D34CA30C5292090AED620D52BDDFC8D5C3C7E0022D

2     1QDCbJSdKunDECwVkTA8AeZ9Mt2cA9rowb
      Pub.Key: 02F2F101E432204C4A32DE32E757413E351FE642FDC707184223FBBB5466579C04

3     17SuCFUbV2g83BPthzkmhFod91VeyyYpRM
      Pub.Key: 02A4FB6AFBBB1DF29AB17F9519EEC77E47E7662E8399158C83F7B35501D36ECD83

4     1HHbDh3zif851finurUphR1fF6TcyqatoA
      Pub.Key: 02C82A90DBB6E1DB6CDC2EDCB2081833C7C85D83254167CAA4C46A5D1C5119764E

Option B:
Code:
0     1Fx11oAE7nSzw1vnxtXJjKU5gkQ6qyeAWQ
      Pub.Key: 02FDC70A76434C3A8F44729866F714188E9FA25BCE0A5C93482CDC306CAFF3E4F1

1     15zdQ2wkXntrMKgs7Pkwq7D4sLVdSjJDPr
      Pub.Key: 032BCD23D0CEA5FDFE622080F9C3BF2680F1D7EEAE8FC56DA64FC2ED536B630E53

2     1J81WVVNjfmoxHSqHgKUzv1aW8gwyX4R9E
      Pub.Key: 023680424FEE801DBBD626D5248189D179C67976D2C9934EEDDB8A8B04FE63E192

3     1LrbvPQQ8yiG5SKnsCAVHbnwHkwKw1hURB
      Pub.Key: 024F69025CF3768AFBB28D03AA9CD90D16BD8382AE021B8719809408C36C8A2401

4     1B88w1HNW6cwRmYSRM32HdX7gtQzWJy4Us
      Pub.Key: 0268E345CD29D1D4FAA9652BE0F47B72170D510655552B56AAB2BEFBAE859BC44E

Option C:
Code:
0     1HpXydZyZhjjbbHwjqXe6CbqTxDrpUV6wg
      Pub.Key: 02425F50BA0E0238528F03FE40FA1BA375DB30092739BC8ED48BB3EA917190CAA4

1     19SubykBdAGChGJV7qzractUuHchv2TGV9
      Pub.Key: 039CE488557C3C72A7FFDE7E81314808516AE2CD227E96A60E1A47814E2413C9D5

2     1MSJu8cv1LFJbvXkVmg2GcB95sjJQv8uS7
      Pub.Key: 030EA81265DCF94528D1A3AB0FF28EEC2A6E2E752A8D4E753B05943D6B82398534

3     1MhXzhgwtviqqx4KtFQTu2eoSLjcEJrPFz
      Pub.Key: 026B68C00DC1EDA7886BB42DD859E58F412E5AC7C7FD25BC99C08C47F16B6CC2D4

4     1FbLCfrHLtgwc9iVaMTWCxPjVDogWbMQyY
      Pub.Key: 036EC441E65F573DFC5B2659D3821575C0044E4C489690C36F77CD84DE6F815D97

Option D:
Code:
0     19PQKSYwGiYo25eqFQu2ZEMUQeEaEfhM72
      Pub.Key: 026CB7302696C9CB5EBE1AFDDBFBE15809E544210EDA0C9307D46AE4311A8593CC

1     18UQk41j7DQbnAjSHvghF4XT7xQcB144Bj
      Pub.Key: 03ECCE5D50902B27BFB99E3C1B3A10F5777CC7118025630D18BA20FD0DEA51F688

2     1CuqcG2Bk2UkffM5xGCrLjADaXQtCvzKrm
      Pub.Key: 0396614D44AB0AD96F348CFA7A1B8C04710819A2C80BB506A801CB239D8B9F7632

3     18LbxdoySf7EHJS1NrCb9yo4UrX8RwoZ2t
      Pub.Key: 02BADC6EF32A885CA1A375CF96BC66002DBE881FF3DC2EC345420689F7CCDC5A66

4     1CoiEc8859xJSEH3dHQWqBL6fczkqo4RQb
      Pub.Key: 03A46B6691853F69E8319720B725A17A83BC55136E43195010DF5DF758BC46A655

Option E:
Code:
0     1Ayg5AAubRcJgxEdWUpBKKG5BqMGBoXsct
      Pub.Key: 03355E414BC4247A5E50C4F2678C3780BD3076926BE80371C841B43989FEA1096D

1     12af3bd7x7BcwpnAK4vJT6WvZgFwzFt2rP
      Pub.Key: 038DB17B8890CD4A8049DBD2D3C9BF8307AFD6567714A71F1B22AF7154BB8316FE

2     1EF6zrRSdm94HjdUdRqLCguoMZab7PHyJf
      Pub.Key: 03721B8BBEDDDD18B218466787E2F072A269DA6D8AD8D181DCB0FFFAD13AF25DDA

3     1EL36j33b4tTUGN5pEBajFttXvM18i9zem
      Pub.Key: 03A633239EE71C05689AAE62BF4C286E4386DB88236A638CD51D9E3E393783AA1A

4     1LYCWdxxrystURtWz9mjnDssomSbkTvkJq
      Pub.Key: 025E77B059394E38F5B44B8FE96FD47F3C9A2A1FA557D3B48F5E58CF30C8008804

Option F:
Code:
0     1Dbgo7M43BmywoBnY1x6MuZkNyiKS3X6uq
      Pub.Key: 029F66217714A8AA2CF5493F9B52898EAAA19466CD70CB390032FE2D4DB2158FD1

1     16uSekTBuMrYavo9iQiJV1MNeay8H3UarH
      Pub.Key: 033A58073D43870A2F112CCDE2ECCDD19F55B90A8B885ACDD60242E773C29707CD

2     1EmGFtfUeQNfNb3EnaVLGAjP6bshimghXy
      Pub.Key: 03A2938B76D31C594E3526868F72BD18FFCEC588234156E4DF7B4593A843767A77

3     1PJyhCszxcN8gV8xRvEiVogQUjJhA3Ji4F
      Pub.Key: 024044CBA5BB113669B7350C8FD41691F8E9F26F6EDFFB1E2C4A7416E23D2EB2AF

4     19jxSLZCUeG5u65baNtAEbTqjtuDP1NvQo
      Pub.Key: 02C278BF4DB75E52019B7EA5FEAF1C541EAFEB87605BD1200F2ECE77C4DF552E3F

Option G:
Code:
0     1FdZxbjc9QaFKgSPLQCu5QfSRWVhSW4ATA
      Pub.Key: 039735DB6B669EF85E0F8883E97C7EEFE5244679CF1B793117050EBA47608ADAD4

1     1BqpuGvqsSBHa5pvsuefxsFQnqXZUH5B4f
      Pub.Key: 03C13515B42DD13CFD5670CF82674AE0299FB01E900A9038E41E2146F73B8395B2

2     13Z8MgJ4bcCzeaK2j5Enezr92CjFgFaNcw
      Pub.Key: 031E2F6B238F26826505CD2407FDAD9BE6B84359A47DA6954A70F78F0A7C5371E3

3     1MyaVy9CciMyMc1KSUCLJfxQUR5WFZYKjD
      Pub.Key: 02FECDED98734080F40042920C6C945ACD91832A3095EDAC78427549B8EA3134D2

4     1EpzR2feGgyweejJWoPeERcbf3jCb3LBDt
      Pub.Key: 02E968FCB36A23C9AE61E789EB57720F610E642C65BB174D7A6994E2456A9DCFD9

Option H:
Code:
0     1AJbwWp64eoPVbtA3S2UG9t4g9h2pLPnqq
      Pub.Key: 02240C4D5E91E8A161CAA4C92139E1D037DCBEB800DF3C6913FB2798EF291E9735

1     19cdF1u9GdgrJUshJTCVvgdvaeathwTaHx
      Pub.Key: 0331A6EBAE0279ED545A24FCDDDAF28BB59FB505C6D6E7E4B34038C838473625C8

2     1BFvirWvd7e2zVNR2pQeyQrFZjquK95xav
      Pub.Key: 02E6E6AB43B08EB0E244EE043F49DBFE1AB21D174396C8AF6F058216F866BDCEAC

3     1NDQbzuYLrkbKSV6r1gNTWQkcBoAeTDoDU
      Pub.Key: 02184CE4C6591A1BADBA9676E325DA3DE76A14CF9A8172A11BE9B5259CC2B8E736

4     1Cnf8NaHDnbYjMeE4TxvDF61DANRvUNJoR
      Pub.Key: 030DE58B172B08A89AEA7C0F7F1380205F2557CA82EB50D271C82676C108107760

Option I:
Code:
0     1CJN29dzkxm9rRm2aGAaQkrXHWyv5ZXFZp
      Pub.Key: 02C4234923632972E51297A9A8333F44FEE1D7A0B51A3C5EE8BF9D8EC497BE55D8

1     19jJ5kTXwmKR15Dg2zb2BtUgRX42uL5Y9Z
      Pub.Key: 033C17C742C8E1164C8654A8B485C046D13F8FD20B66F6E08E17A94187D379F89F

2     1PRwoPu9NyZyHy1M1HySmSjWhWnHV3Q3GS
      Pub.Key: 03D5508D6CF212C43BD1581417D399C0373C1DDAE0BCF7A98AC5114FFB35F0D5AE

3     1HCjrSnPcEy1PXFX7sa9QPXTyQF5KJTs3A
      Pub.Key: 0323D2D6EC89F30401B569AA1684F2F2E0251F4EC2CD135351C2124D33C07C8C87

4     18oJDyHNvdmN4g9x84rnv5e4b5Qg3769QR
      Pub.Key: 02939A94E558B1F40E2415D2F6BB019BD349D6E5B869A4A9CDF7D851025B614945

Option J:
Code:
0     16cAHfhHD3txXhLaQPDktig9oy56kDcPEv
      Pub.Key: 034F4A5B215077512A91C05AF8AEB787ECAC586A5E05E60ED121709AC224DF5691

1     1JAFeaKgKiTMKf6eDMFyTdhWsKFDSdjxEj
      Pub.Key: 03E7853E8F5FE607410C3DF43ABF71050C2ED8C16B1FBC1BA90D93C4EF6681F0D3

2     1K746TgpUHNbxxAd1EwKMh2SBMBMaoqG4r
      Pub.Key: 02DE4A2C0A46505D99B86EE41EFDA6DDB2731E5821119C12414C7EDE1C7DCD305B

3     1Gn8torjmDdtXx8DZMpnuYBXZWotAwwq6y
      Pub.Key: 031B81A9B99EA06900A8E3530A8732F77ACE30E916733FDFEEDDAF3BD80C509CE7

4     1NQYJ5ZaJZwVn1KkPcdye4Ytu4xYYRkFYL
      Pub.Key: 03BEDECD9AC2916BE4E6012E2936901B1CC0F4A4D44F658757E10140CB75E54FDA


Now I am very curious: Can you tell, which of the public key sequences A-J above is derived from the same mnemonics HD wallet as above (plus a different password)?

If yes, you have proven by example that the plausible deniability of "BIP39+password" is in fact attackable.

Otherwise, it yet needs to be proven - or I completely missed something.
14  Local / Deutsch (German) / Re: Lieferando: "Zu wenig Kunden würden Bitcoin nutzen" on: July 11, 2015, 10:30:30 AM
2 Jahre später... mir schreiben sie nun:

Quote
Wir haben Ihre Idee* an die zuständige Abteilung weitergeleitet und freuen uns Ihnen mitteilen zu können, dass Bitcoin in Kürze zur Verfügung stehen wird.

* "Idee" bezieht sich auf meine E-Mail mit dem Vorschlag, Bitcoin als Zahlungsmethode einzuführen, wie es lieferservice.de bereits tut.

Bemerkung: Da lieferando.de ja auch im Fernsehen wirbt und dabei auch Symbole der vielen verschiedenen Zahlungsmethoden einblendet, besteht die Hoffnung, dass in Zukunft auch das Bitcoin-Symbol im Fernsehen zur besten Sendezeit eingeblendet wird.

Edit: Hab gerade gemerkt, dass lieferservice.de mit lieferando gemerged ist und damit momentan(!) auch keine bitcoins mehr akzeptiert. Das wird sich dann also in Bälde wieder ändern - hoffentlich.
15  Bitcoin / Wallet software / Re: [ANN] Bither - simple&secure Bitcoin mobile wallet.(iOS v1.3.1 + HDM) on: March 01, 2015, 01:23:37 PM
Hello,

I am fascinated to see Bither evolve and progress!

Is this signature format a Bither proprietary format, or a format compatible with other Bitcoin clients (which) like Electrum , Armory, ...?
(i.e. can Bither verify signature strings from client ABCXYZ, or vice versa?)

Hello,

Me too! They are makimg it better!

I was successful in verifying, so I think it is compatible with other clients.

   -MZ

Which "other client" did you use? I think Electrum and Armory use different formats...
16  Local / Trading und Spekulation / Re: Bitcoin Trade-Manager: Spreadsheet listet (Ver)Käufe und berechnet G&V und mehr on: March 01, 2015, 03:24:00 AM
Danke Vaagar,

sorry für meine späte Antwort (hab inzwischen nichts mehr an dem Tool gemacht, weil es für mich tut was es soll), vielen Dank für deine konstruktive Kritik!

Meine Antworten zwischen den Zeilen:

So habe mir das ganze mal angeschaut und damit etwas rumgespielt (etwa 30 Minuten).

Wichtig es handelt sich hier um meine subjektive Meinung.
"->" gekennzeichnete könnte eventuell ein Lösungsvorschlag durchgehen Smiley

- Zu unübersichtlich da Sheet zu Breit
-> Das Ergebnis zusammengefasst auf einem Tabellenblatt und die Daten mit dem alles gefüttert wird auf Tabellenblatt 2 packen
OK, das hängt vom Bildschirm ab... Bei mir passt alles von Spalte A-V auf den Bildschirm (bei 80% Zoom=Voreinstellung), die graue Tabelle (Spalten X-AB) ist eigentlich nicht wirklich so wichtig. Für die Bildschirme, wo nur Spalten A-P in der Breite draufpassen (oder wann man sich die graue Tabelle rechts eben doch mal ansehen möchte), gibt es oben links den immer zugänglichen grauen Button zum horizontalen Scrollen, der mit der Aufschrift "<= Links <=> EURO-Tabelle =>". Die Pfeile sollen andeuten, dass es sich hier um eine "Scroll-Hilfe" handelt. Ist sehr bequem - einfach mal ausprobieren.

Die Dateneingabe und Ausgabe auf zwei unterschiedliche Datenblätter zu verteilen wäre auch möglich, allerdings wollte ich gerne alles auf einen Blick haben, darum hab ich mich für diese Variante entschieden - alle Informationen im Blick. Geschmackssache.

Quote
- Die Spaltenbezeichnungen sind etwas verwirrend und leider nicht Selbsterklärend
  EUR/XYZ hab ich dank Anleitung rausgefunden, dass hier der Wechselkurs gemeint ist, wenn ich hier in Euro handel muss ich das Wechselkurs 1 eintragen?
  Preis BTC/XYZ: Hier gehe ich von aus das der Kurs vom BTC / zur Fremdwährung gemeint ist?
  Gebühr XYZ: Nur eintragen wenn Gebühr in Fremdwährung oder auch in Euro?
Die Fragen sind alle berechtigt. Genau deshalb gibt es in den Spalten-Überschriften Tool-Tips, die genau den Zweck haben, genau diese Fragen alle "rückstandslos" zu beantworten. Hast Du wahrscheinlich einfach komplett übersehen.

Für mich sind Tooltips für sowas immer der "natürlichste Ort", um entspr. Hilfetexte unterzubringen.

Quote
- Keine Möglichkeit Transaktionsgebühren seperat anzuzeigen
-> Eintrag mit Transaktionsgebühr 0,0005 BTC erzeugen, sind etwas blöd abzubilden, hier müsste ich dann Hingehen und schauen welchen BTC ich zu letzt gekauft habe Preis 300 (FiFo) und dann einen Verkauf eintragen mit: Verkauf 0,0005 BTC (Transaktionsgebühr) zu 0 Euro, Gebühr 0,15 Euro Gebühr.  Oder mann sagt einfach Verkauf 0,0005 BTC zu 0 Euro und am Ende des Jahres müsste es in der GuV auch passen. Ist beides leider nicht so ganz "optimal"
Du meinst jetzt die Bitcoin Netzwerk Transaktionsgebühren, nehme ich an? In der Tat hab ich daran gar nicht gedacht.
Wenn man diese auch berücksichtigen möchte, dann müsste man in der Tat in dem Tool, wenn man 0,0005 BTC Netzwerk TX fee bezahlt hat im Zusammenfang mit einem Kauf/Verkauf, eine zweite Zeile eintragen, in der man dann einfach angibt, dass man 0,0005 BTC (Spalte E: "-0,0005") zum Preis von 0 EUR/BTC (Spalte D: "0") verkauft hat, die Spalte F (Gebühr) bleibt einfach leer (ich weiß nicht, was Du mit den "0,15 Euro" in Deinem Beispiel meinst). Auf diese Weise reduziert sich mein Bitcoin-Bestand um 0,0005 BTC, während der EUR-Inflow/Outflow unverändert bleibt.

Quote
- Berechnung von Gebühren erfolgt nicht automatisch.
-> Eventuell eine Legende mit Gebühren hinterlegen? Bei variablen Gebühren wie bei Kraken wäre das etwas komplizierter.
Wie soll das "automatisch" gehen können - das Tool ist ja kein "Hellseher" das die Gebühren "ahnen" kann. Auch sind die Gebühren pro Handelsplatform keineswegs einheitlich sondern hängen teilweise vom Umsatz ab (z.B. Bitstamp), sind auch Schwankungen unterworfen etc. (z.B. Bitstamp). Darum muss man die auf der Handelsplatform zum jew. Trade angefallenen Gebühren in Spalte F explizit angeben, eine andere Möglichkeit sehe ich nicht.

Für Bitcoin.de habe ich dennoch einen Gebühren-Berechnungs-Assistenten implementiert, um sich das Leben einfacher zu machen! Man trägt einfach die Brutto-Daten aus der Bitcoin.de-Übersicht der Käufe/Verkäufe ein, markiert dann die jew. Zeilen und klickt dann den "bitcoin.de"-Button. Dann werden die Gebühren laut bitcoin.de-Formeln exakt korrekt berechnet, und bei Käufen wird auch der Brutto-Betrag auf den entspr. Netto-Betrag korrigiert, entspr. bitcoin.de-Formel. All das erfolgt auf den Satoshi genau und auf den Cent genau, ich habe es bei unterschiedlichsten Trades (Krumme Zahlen, Käufe, Verkäufe, ...) meinerseits überprüft - es stimmt immer ganz genau ohne jeden Rundungsfehler.

Quote
- Eine Excel-Version wäre nett gewesen.
Ja... Ich habe einen Linux-Rechner mit LibreOffice, und entsprechend habe ich die LibreOffice/OpenOffice Macro-Sprache benutzt. Leider nicht mit Excel kompatibel.
Also werde ich so schnell leider keine Excel-Version erstellen - es wäre im Wesentlichen Fleißarbeit, alle Befehle nach Excel-Syntax umzustellen, würde aber sicherlich ziemlich zeitaufwändig sein.

Insgesamt denke ich, es ist zumutbarer, sich zusätzlich zu MS-Office noch das kostenlose LibreOffice zu installieren (das beißt sich ja nicht, und Festplattenplatz sollte in der heutigen Zeit i.d.R. auch kein Thema mehr sein), als umgekehrt. Andererseits hat MS-Office natürlich die größere Verbreitung - aber dann gibts vielleicht auch wieder Inkompatibilitäten zw. MS-Office 2000, 2003, 2007, 2010, 365, ... und jeder hat eine andere Version ... wer weiß(?!?).

Quote
Werde dennoch mal schauen ob ich nicht diverse Tabellen gegeneinander antreten lasse, im nächsten Jahr.
Gerne Smiley

Viele Grüße
Michael
17  Bitcoin / Wallet software / Re: [ANN] Bither - simple&secure Bitcoin mobile wallet.(iOS v1.3.1 + HDM) on: March 01, 2015, 02:29:58 AM
Is there any plan to incorporate "hidden private key" feature for "plausible deniability" to "Bither" wallet (as detailed in the OP of "https://bitcointalk.org/index.php?topic=361386.0")?

This would be a very useful feature to protect against violent physical theft of bitcoins, and I think up to now it is not implemented in any wallet software yet.

Generally, everybody is concerned about good technical cryptographic protection (for very good reason of course!!). But we should also be concerned about PHYSICAL theft: What if someone points a gun at me to hand over my private keys?! --> There is a very simple and effective solution of how a user can give his private key to a thief while still keeping his life savings.

This scheme could be implemented in both BitherCold and BitherHot (in the latter case for the "hot private keys").

I am not going to repeat how it works exactly here, because I have detailed it in the link above, so please just refer to that post to understand the motivation and the solution, but in short, the basic principle goes like this:

  HiddenPrivateKey=sha256(NormalPrivateKey||MoreOrLessSimplePassword)

  • with "||" denoting simple "concatenation",
  • with "NormalPrivateKey" being the private key as it is stored in the Wallet software today, and
  • with "HiddenPrivateKey" being a temporary key calculated upon the user's selection of the NormalPrivateKey's Address and typing of a password. This hidden key should only reside in RAM memory temporarily while the user makes a transaction, and never leave any traces in flash memory. Obviously, the user should also not store the address of this hidden key in his list of watch-only-addresses, because this would render it less plausible to deny possession of that key.

  Clearly, if someone steals the phone and knows the PIN, he can access the NormalPrivateKey but has no idea that another (or several other) "HiddenPrivateKeys" even exist.

The method is good for BitherCold for evident reasons (theft protection), but also for BitherHot if I want to take some Bitcoins with me on a journey but don't want to loose them all if I move with my smartphone into an unsecure neighborhood and get robbed...
18  Bitcoin / Wallet software / Re: [ANN] Bither - simple&secure Bitcoin mobile wallet.(Android v1.2.2 released) on: March 01, 2015, 01:31:54 AM
Bither Android v1.2.3 released  Cheesy
1. Message signing and signature verification.


Hello,

I am fascinated to see Bither evolve and progress!

Is this signature format a Bither proprietary format, or a format compatible with other Bitcoin clients (which) like Electrum , Armory, ...?
(i.e. can Bither verify signature strings from client ABCXYZ, or vice versa?)
19  Economy / Service Announcements / Re: [ANN] Telebit - built-in bitcoin wallet for telegram users on: February 21, 2015, 10:50:23 PM
Unfortunately, the text based user interface and the non-intuitive set of actions required on the telegram GUI to initiate btc transfers to other users makes it completely unsuitable for the normal (non-tec-savy) user.

what is needed is to have the BTC wallet built-in to the telegram GUI. unfortunately, this is unlikely to happen, since telebit is not affiliated with telegram.
20  Local / Trading und Spekulation / Re: Bitcoin Trade-Manager: Spreadsheet listet (Ver)Käufe und berechnet G&V und mehr on: December 01, 2014, 02:00:05 AM
Hallo ihr über 350 "Draufklicker"!

Ich würde mich über Feedback freuen. Nützlich? Verständlich? Bisher mache ich hier ja nur "Selbstgespräche".

Ein Feature plane ich übrigens noch nachzureichen! --> Nämlich ein automatisches Sortieren der Liste nach Datum. Dadurch wäre es möglich, bequem pro Tauschbörse die Transaktionen nacheinander untereinander einzugeben, und dann per Klick alles chronologisch sortieren zu lassen. Ich glaube, das würde noch einen deutlichen praktischen Mehrwert bringen, oder?
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!