Bitcoin Forum
October 03, 2023, 10:55:37 AM *
News: Latest Bitcoin Core release: 25.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 30 31 32 33 34 35 36 37 38 39 40 »
1  Bitcoin / Development & Technical Discussion / Same private key for 02 and 03 key with same X coord? on: October 12, 2018, 01:12:12 PM
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.
2  Bitcoin / Development & Technical Discussion / Re: How to place tx in own mempool without broadcasting? on: February 16, 2018, 04:59:21 PM
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!
3  Bitcoin / Development & Technical Discussion / How to place tx in own mempool without broadcasting? on: February 15, 2018, 03:43:34 PM
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?
4  Bitcoin / Development & Technical Discussion / Re: Private/public key generated by bitcore API issue!!! please help on: October 13, 2017, 10:58:49 AM
it is a string "115792089237316195423570985008687907853269984665640564039457584007908834671663" or something else..?

It's the value of the moduli. It is the biggest number in the curve secp256k1 that bitcoin uses.

If your generated private key is bigger than that, then you have to subtract that number from your generated key as many times as necessary, until it becomes smaller than that number.

The security of bitcoin depends on big numbers. That is the reason why the moduli has to be so big.

for example :
Here is my private key ="9c63e8e2f6574c197c0626bad843eb47104adf3f01f2901aad1258936feb007e"
var newprimarykey = (9c63e8e2f6574c197c0626bad843eb47104adf3f01f2901aad1258936feb007e * 36453278) mod 115792089237316195423570985008687907853269984665640564039457584007908834671663 );

console.log('newkey = ',newprimarykey);

If i am executing this one then it'll give error :

var t1 = (9c63e8e2f6574c197c0626bad843eb47104adf3f01f2901aad1258936feb007e * 36453278);

SyntaxError: Unexpected identifier
    at exports.runInThisContext (vm.js:53:16)
    at Module._compile (module.js:373:25)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Function.Module.runMain (module.js:441:10)
    at startup (node.js:140:18)
    at node.js:1043:3

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.
5  Bitcoin / Development & Technical Discussion / Difference between version 1 and version 2 transactions? on: September 04, 2017, 09:55:43 PM
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.
6  Bitcoin / Development & Technical Discussion / Re: Vanitygen: Vanity bitcoin address generator/miner [v0.22] on: September 03, 2017, 10:54:57 PM
Is there a way to get this to find Segwit P2SH (P2WPKH program inside P2SH) addresses?
7  Bitcoin / Development & Technical Discussion / Re: How to judge illegal transactions? on: August 28, 2017, 11:04:46 PM
I wonder how the bitcoin protocol judge illegal transactions. As they say, the miner will look throughout the public ledger to make sure the transaction is alright. There are thousands of transactions in each block, if the miner has to check throughout the public ledger for each transaction, this would be very inefficient.

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.
8  Bitcoin / Development & Technical Discussion / Re: Can Bitcoin Script be extended to be Turing Complete? on: August 28, 2017, 11:02:38 PM
If Brainfuck is Turing complete, then unused Bitcoin op codes can become Turing complete.
9  Bitcoin / Development & Technical Discussion / Re: Fork-Attacks on bitcoin like Bcash and B2X might become infeasible after halving on: August 28, 2017, 10:59:24 PM
A fork is not an attack.  It is a fork.  Bitcoin does not care about forks, because they are not Bitcoin.
10  Bitcoin / Bitcoin Technical Support / Re: How to stay with legacy address format? on: August 28, 2017, 10:56:42 PM
When somebody asks you for your Bitcoin address because they want to send you some, give them the bolded address.


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.
11  Bitcoin / Development & Technical Discussion / Re: Off-chain proof of commitment for Bob to pay Charlie before Alice pays Bob..? on: July 25, 2017, 05:04:20 PM
It doesn't have to be on-chain. The blockchain is only used in case of a dispute between the parties involved. In that example they say dave claims his payment by broadcasting a transaction on-chain and in doing so reveals the secret allowing bob to get paid too. But in practice dave would simply reveal the secret to bob off-chain and keep the payment channel open for future transactions.

Also you should read the official lightning docs section for HTLCs because it's a little more complicated than that in practice:

Fantastic, thank you for all your help!
12  Bitcoin / Bitcoin Discussion / Re: Is there an agreed currency code for Bitcoin? on: July 23, 2017, 09:51:33 PM
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.
13  Bitcoin / Development & Technical Discussion / Re: Off-chain proof of commitment for Bob to pay Charlie before Alice pays Bob..? on: July 23, 2017, 09:44:24 PM
lightning wouldn't be very useful if this wasn't possible:

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?
14  Bitcoin / Development & Technical Discussion / Off-chain proof of commitment for Bob to pay Charlie before Alice pays Bob..? on: July 22, 2017, 11:09:31 PM
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?
15  Bitcoin / Development & Technical Discussion / Re: What is in the pipelines for fixing SPV mining incentives introduced in Segwit? on: July 07, 2017, 07:59:15 PM
Awesome, thanks so much for catching me up!!
16  Bitcoin / Development & Technical Discussion / What is in the pipelines for fixing SPV mining incentives introduced in Segwit? on: July 07, 2017, 04:41:40 PM
I am talking specifically about what Peter Todd talks about here:

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.

17  Bitcoin / Bitcoin Discussion / Re: Bitcoin market crash on: June 24, 2017, 09:37:00 AM
I'm just curious. What if bitcoin and any other alts market fall and you invested all your money into this. Would you rather do Panic Selling? and How would you compensate all your losses?

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.
18  Bitcoin / Development & Technical Discussion / Re: Can Someone Explain to me the old IP to IP TX system? on: June 24, 2017, 09:23:18 AM
This obviously has some privacy implications and likely some vulnerabilities so it was removed.

However, this explanation is useful but not sufficient. So it was a contentious removal. But now that no one vocally wanted this feature in the past years, it looks like that we can safely remove it. Maybe we will add it after decades. Just keep it in mind.

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.
19  Bitcoin / Bitcoin Discussion / Re: Poll: Has Theymos been hacked or hijacked? on: June 24, 2017, 09:18:07 AM
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.
20  Other / Bitcoin Wiki / Re: Request edit privileges here on: May 13, 2017, 07:50:47 AM
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.
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 30 31 32 33 34 35 36 37 38 39 40 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!