I dedicated a new thread for this:

https://bitcointalk.org/index.php?topic=5526769.msg64963225#msg64963225

Is it possible to "pay to many" in ANDROID(!) Electrum?

I tried to "paste from clipboard" the invoice string in many different ways, but none of it worked.

For SINGLE output the following formats DO work with copy-paste:

1BitcoinEaterAddressDontSendf59kuE

bitcoin:1BitcoinEaterAddressDontSendf59kuE

bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0008


For MULTIPLE outputs NONE of the following works:

1BitcoinEaterAddressDontSendf59kuE,123AnditsGone111111111111111Ymiao1

1BitcoinEaterAddressDontSendf59kuE
123AnditsGone111111111111111Ymiao1

1BitcoinEaterAddressDontSendf59kuE,0.0008
123AnditsGone111111111111111Ymiao1,0.0009

1BitcoinEaterAddressDontSendf59kuE,0.0008;123AnditsGone111111111111111Ymiao1,0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008,123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008&123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008&123AnditsGone111111111111111Ymiao1&amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008,bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008
bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009

bitcoin:{1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{123AnditsGone111111111111111Ymiao1?amount=0.0009}

{bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009}

{bitcoin:1BitcoinEaterAddressDontSendf59kuE?amount=0.0008},{bitcoin:123AnditsGone111111111111111Ymiao1?amount=0.0009}


Now I am running out of ideas what other formats I should try. Any ideas? Or is it not possible on the Android version?

I have to add an additional Info:

I now remember that I had created the raw (unsigned) transaction not with Electrum 1.7.x but with "https://coinb.in/#newTransaction" - and then I signed with Electrum 1.7.x on my old offline Linux PC (with equally old Linux version)!

So do I understand correctly that here - in the ray RX already - the "non-standard stuff" was created leading to "scriptsig-not-pushonly" error?

Any ideas what I can do (maybe via advanced settings there?) to get a workable raw TX?

Thanks a lot for your very good explanation. Makes sense and I am afraid I have to go through these tedious steps...

One more question: Is it possible to extract the unsigned TX HEX string from my signed TX HEX string? (ideally by omitting some parts or be using a command line tool or so). If yes, I can save substantial effort by not needing to re-build the entire TX again (esp. because I have many of thoise TXs with 1 input and N (N=many) outputs).

Or is the non-standard thing that casues my problem already included in the unsigned TX and not in the signing part?

Hmm, yes, probably it is something like that. But there is no mention of "electrum" in your link...

I created a raw transaction with an older electrum version (1.7x or so). It verifies correctly on "https://coinb.in/#verify", it is a TX with 1 input and 4 outputs and it has sufficient TX fee and has in- and outputs that are larger than just dust.

I cannot broadcast it anywhere. I always get error messages like these:

https://coinb.in/#broadcast
--> the transaction was rejected by network rules. scriptsig-not-pushonly

https://blockstream.info/tx/push
--> RPC error

https://www.blockchain.com/de/explorer/assets/btc/broadcast-transaction
--> "Code: -26, Error: scriptsig-not-pushonly"

https://www.viabtc.com/tools/broadcast
--> Raw transaction send failed

https://live.blockcypher.com/btc/pushtx/
--> Error validating transaction: Rejected script for input 0 referencing ......

https://blockchair.com/broadcast
--> An error has occurred, please verify the transaction hash and selected network and try again.

https://bitaps.com/broadcast
--> Mempool accept test failed: scriptsig-not-pushonly

Finally I tried Electrum on Android with the "paste" button from clipboard. Again same problem (I translate error message to English):
--> The server has answered with an error. Try to select another server or to install an update of Electrum. scriptsig-not-push-only
(I tried about 10 different servers - all the same problem, then I gave up)

What can I do to broadcast this TX?

I created a raw transaction with an older electrum version (1.7x or so). It verifies correctly on "https://coinb.in/#verify" but I cannot broadcast it  anywhere. I always get error messages like these:

https://coinb.in/#broadcast
--> the transaction was rejected by network rules. scriptsig-not-pushonly

https://blockstream.info/tx/push
--> RPC error

https://www.blockchain.com/de/explorer/assets/btc/broadcast-transaction
--> "Code: -26, Error: scriptsig-not-pushonly"

https://www.viabtc.com/tools/broadcast
--> Raw transaction send failed

https://live.blockcypher.com/btc/pushtx/
--> Error validating transaction: Rejected script for input 0 referencing ......

https://blockchair.com/broadcast
--> An error has occurred, please verify the transaction hash and selected network and try again.

https://bitaps.com/broadcast
--> Mempool accept test failed: scriptsig-not-pushonly

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

post #25's method should be safe.

you are not meant to print and rescan the image with the method of this thread. This won't work.

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?

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!

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?

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!

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.

Hello erik,

thank you for reading and commenting.

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.

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.

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".

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.

I now wrote it in BIP format at Github:

• BIP Format at Github

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):

• BIP Format at Github
• SCRIBD: https://de.scribd.com/doc/278450599/A-Hybrid-Mechanism-for-Adaptively-Adjusting-Bitcoin-s-Block-Size-Limit-BIP10X-Short-Overview
• DROPBOX Download: https://www.dropbox.com/s/mw3e30kju9t86uj/BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf?dl=0

Please judge it by the content and not by the fact that I put it on dropbox.  Thanks!

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:

• BIP mediawiki format at Github

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

• BIP10X_Block_Size_Limit_Adaptation_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_v02.pdf Dropbox Download

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):

• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf from scribd.com
• BIP10X_Block_Size_Limit_Adaptation_Overview_v02.pdf Dropbox Download

Looking forward to hearing from you!  
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.

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: (i.e. no password at all!)

The first five addresses and key pairs are:

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:


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:

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:

Option B:

Option C:

Option D:

Option E:

Option F:

Option G:

Option H:

Option I:

Option J:


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.