In this reddit thread, somebody is claiming that a private key can be used to derive two different public keys which share the same X coordinate.  i.e. the same private key can derive both an 02 key and an 03 key with the same X coord.

I was under the belief that was not true and that an 02 key is an entirely different key from an 03 key with the same X coordinate, and that a given private key will only ever correspond to either an 02 or an 03 public key.

Is my understanding mistaken?  Can a private key be associated with both a 02 and 03 key (that have the same X value)?

Edit:  Nevermind, it looks like he pointed me to where this was specified.  Thank goodness, I'm not going crazy.

Oh gee that's a good idea.  And that just applies to the RPC call, right?  So it wouldn't interfere with broadcasting the transaction if/when the block is mined..??

Assuming that's the case, that's exactly what I'm looking for, thanks!  One quick question, is that code you highlighted also responsible for using sendrawtransaction via the bitcoin-cli program, or do I need to find and commend out code somewhere else for doing it via the cli?  Either way, it's no trouble to use the RPC interface, so you've definitely given me a working solution.  Thanks!

Is there a way I can add a transaction to my own memory pool without broadcasting it to the network?  Imagine I am mining my own transactions and want them kept secret from the network unless they are in a block.  (For example, a time-locked commitment that triggers another event which I want to make sure can only happen AFTER my tx is in a block.)

As far as I can figure, the only way to do this is to mine the transaction myself.  And right now, the only way I can think to do that is to run two nodes where one is a bridge "blocks only" node and is the sole node that the other (mining) node connects to.  Then I can add transactions to the mining node manually.  But then it won't know about any other transactions on the network that I might want to also include in the block I am mining.

Is there a way to accomplish this?  To have my transaction in my block template without broadcasting it?

I'm not a JS dev, but... you do know you have to convert the hex to decimal, right?  The private key is a hex representation of a really large number.  And I assume JS has some kind of BigInteger library or something for large numbers, which you would need to be using.

So you need to convert your private key from hex to decimal, THEN multiply it, and THEN take the result mod that other large number.

That said, you probably should not do any of that.  Instead, you should use the private key as a BIP 32 seed, and use a BIP 32 HD master key to generate your keys.  That's the best way to generate a bunch of addresses from one master private key.

I've seen segwit transactions as both version 1 and version 2.  When should version 2 be used versus version 1?

Example version 2 tx:  c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a

Example version 1 tx:  4ffb6404517ad30869f125b7f2f23a9058313d736a72a996b1381f1fe6f04e07

Both are in blocks on mainnet.

Is there a way to get this to find Segwit P2SH (P2WPKH program inside P2SH) addresses?

Every full node does this.  That's why syncing takes forever.  Yes, it's inefficient.  But it's also the only way we know how to have such a system operate.

If Brainfuck is Turing complete, then unused Bitcoin op codes can become Turing complete.

A fork is not an attack.  It is a fork.  Bitcoin does not care about forks, because they are not Bitcoin.

When somebody asks you for your Bitcoin address because they want to send you some, give them the bolded address.

12sziC91z7hwfpVDNw7UbsisaapBwFtW7t
337cKTRkrmfXHMRKgk1xosqsEY6dToRD7h
bc1qzjw3jywhf2r7k24y3gqj0fs4apddg03pujsjzx

Each of those represents the same Bitcoin key, but they are very clearly different.  You will always be able to use the legacy Bitcoin address format, aka the first one.  I can't imagine any wallet software not letting you see a legacy version address of any of your public keys.

Fantastic, thank you for all your help!

BTC is the most popular and common.  XBT was introduced because BTC was not in line with traditional standards for official ISO currency notation.  Both are used, just get used to them both and recognize they're the same whenever you see one or the other.  BTC is the original and still the most widely used, but XBT may take over if more "official" bodies start adopting Bitcoin.

Thank you for that extremely helpful post!  Now my next question is, how do you do that off-chain.  The whole point of going from A to B to C to D is that they are all connected to each other via previously opened payment channels.  If you have to make a new address and thus a new payment channel which incorporates the hashed secret, then you have to make an on-chain transaction, and Alice might as well just open the channel directly with Dave, rather than going through Bob and Charlie.

The assumption here is that on-chain transactions are costly, and thus Alice greatly prefers to go through existing payment channels without needing to open another one.

So is there a way to use segwit to accomplish this with already opened channels?

I can require some information by having it be the solution to a separate input, and my own input is signed with SIGHASH_ALL locking that input requirement in... except that lightning channels require SIGHASH_NOINPUT.

What kind of payment channels are available where I can add a hash lock condition on an update to a pre-existing channel?

Now that segwit is locked in, I'm thinking about designing some topology on top of the current lnd software.

I imagine a wallet software where the wallet software company is a hub that has an arbitrarily large amount of funds to dedicate to being locked up in payment channels. So the user downloads a wallet, and whenever the user requests one of his addresses to be displayed for deposit or payment, he's actually shown a payment channel multisig.  He doesn't know or care about this, it's just how the wallet operates.

So the wallet is a spoke that connects to the hub run by the wallet software company, which also maintains very large (in value) payment channels to various other hubs run by exchanges and large merchants and such.

Now, our user wants to make a payment to some other user who is connected some hub somewhere else.  For example, Alice and Bob have a channel, Bob and Charlie have a channel, and Charlie and Dave have a channel.  So when Alice wants to pay Dave, Alice pays Bob who pays Charlie who pays Dave.  Bob and Charlie are hubs in this example, and Alice and Dave are users -- although it really doesn't matter.

My question is -- is there a way for Alice to be sure that Bob will pay Charlie and Charlie will pay Dave?  Alice only has a channel with Bob, so if she pays Bob, Bob can just keep the money.  How can Alice be assured that Bob will pay Charlie (and Charlie will pay Dave), and be sure those transactions are committed to before Alice makes the payment to Bob?

(All of this is presumably off-chain since every player is involved in a current open payment channel with each of his neighbors.)

Are there current solutions to this that I'm just not aware of, or is this a problem I need to figure out how to solve?

Awesome, thanks so much for catching me up!!

I am talking specifically about what Peter Todd talks about here:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012103.html

I have been away from the space for a bit and would like to catch up on things, and I was hoping somebody could link me to any IRC chats or other things not just in the mailing list for me to read over.

I am not particularly worried about this, because I think there are enough fully validating nodes that invalid blocks will be caught, but still, it is a new economic incentive towards less security, which is of course a potential issue.

I'm sure it's already been dealt with or is being dealt with, and I am hoping somebody can link me to the most recent advances in that regard, so I can get all caught up.

Thanks!

I did this and am currently broke.

I used to play poker professionally, and I had 30-40 percent of my money sitting in Bitcoin since about 2011.  In 2014 after the $1200 high, crash to $600, and settling around $800, I stopped playing poker almost entirely, dumped the rest of my money into Bitcoin, and spent the next few years on some personal pursuits, including learning to program so that I could contribute to Bitcoin-related projects.  I ran the numbers and decided that as long as Bitcoin didn't go below $300 for more than a few months, I would be OK.  I decided that was a reasonable risk to take.  Then it went below $300 for most of 2015, and I was sad :-(

I'm now in my mid-30s, living in my parents' basement feeling an idiot, and going to grad school to get a master's in CS, because I don't know what else to do.  I don't have enough money to play cards again, and I don't have any real work experience since I made my money playing poker during and after I got my bachelors, until I dumped it all in Bitcoin and everything went to hell.

10/10 would recommend.

It will likely never get reintroduced.  Bips 70-73 offer a safe and secure system for getting public keys and paying websites or IP addresses.

The thing you have to understand about the ardent small-blockers is that they really genuinely believe they are protecting Bitcoin from a very real existential threat.  If Bitcoin's security properties get diminished, there's no going back, no undoes or fixing the problem.  It is a permanent change that irreparably weakens Bitcoin.  What you view as overly zealous conservatism they view as appropriate caution given the risks involved.  Now, I happen to think even given the risks that they are overly conservative, and I support a hard fork blocksize increase... but I don't begrudge them for sticking to their guns when from their point of view, they are defending Bitcoin's very existence from what they perceive as a very real threat that might destroy Bitcoin.

Request for edit privileges.

I posted in the IRC a few days ago, and no one was around, although to be fair I didn't stick around very long waiting for a response.

Username:  [redacted]

This request post will be deleted if/when edit privileges are granted, as I like to try to keep my identities segregated.  If this post is quoted, I respectfully ask that the username shown above be redacted.

Edit:  Redacted username.  It appears somebody is watching this thread, because I did get approved.  Although I posted here and also asked in the IRC channel, so it's possible that the IRC channel was the reason.  Who knows.