Bitcoin Forum
November 17, 2018, 07:54:34 PM *
News: Latest Bitcoin Core release: 0.17.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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 ... 547 »
561  Bitcoin / Development & Technical Discussion / Re: Point addition / double formulas in Bitcoin on: February 01, 2018, 03:44:44 PM
The code that Bitcoin Core uses for ecdsa operations on the secp256k1 curve can be found here: (it's its own library). There are comments throughout the code and some additional documentation on the readme that should help you understand what it is actually doing.
562  Bitcoin / Bitcoin Technical Support / Re: issue with bitcoin-qt and new ubuntu 17.10 on: February 01, 2018, 02:22:37 AM
Can you post your debug.log file?

This looks more like a problem with your X server rather than Bitcoin Core.
563  Bitcoin / Development & Technical Discussion / Re: [LN] What is revocation key? How does revocation works on bitcoin blockchain? on: January 31, 2018, 04:24:00 PM
The meaning of word revocation means that I can somehow cancel the tx, however given the nature of blockchain transaction I struggle to understand how this is possible. Could someone please explain meaning of revocation in this context?
When a new commitment transaction is made, the old one should become invalid. However commitment transactions are not broadcast to the network, rather they are kept private and only broadcast when you want the channel to close. But because all commitment transactions are technically valid, we need some way to prevent people from broadcasting old commitments as they would effectively allow them to steal money. That's where the revocation key comes in.

During the process to create a new commitment, the revocation key for the commitment being invalidated is revealed to the other party. In this way, if you were to broadcast the old commitment, the other party would have the revocation key and can thus broadcast a punishment transaction where they use the revocation key to take all of the funds in the channel.

The revocation key itself is basically the combination of two keys. What effectively happens is that both parties provide a public key at commitment transaction creation time, and those public keys are combined to create the revocation public key. Then when the commitment is replaced with a new one, the party who is having their commitment revoked (remember that each party has their own personalized commitment transaction and the revocation keys are "personalized" for each commitment) reveals their revocation secret to the other party. This secret is combined with the other party's own revocation secret to create the full revocation key. In this way, the party who would have his commitment revoked with that key does not have access to the full revocation key.
564  Bitcoin / Development & Technical Discussion / Re: Going back to Jonald Fyookball's "Mathematical Proof That the Lightning Network" on: January 31, 2018, 04:11:12 PM
Was Jonald Fyookball's assumption on what he thinks on "what the ordinary people think of what the Lightning Network should look like" wrong?

Because everything looks decentralized on mainnet. Look at this

Was Lightning supposed to be "distributed"?
Lightning is supposed to be "distributed", and it has thus far shown to be fairly distributed.

Jonald's assumption of what lightning would actually be like is wrong.
565  Bitcoin / Development & Technical Discussion / Re: MuSig: Schnorr Multisig and signature aggregation on: January 31, 2018, 04:00:10 PM
oh look MUsig for bitcoin can be K-of-n
No, it can't. MuSig itself cannot be k-of-n, but it can be used in applications that are k-of-n. Additional work must be done to make that happen, and it can and will be done where the participants in the multisig know who the others are and have proof that there are actually n people in the multisig, not some other number.

Again, you don't seem to understand what interactive and non-interactive means. It has nothing to do with "seeing the backroom players". All that interactive means is that the people in the multisig prove that they didn't make up some bullshit public key. Yes, they will see everyone involved. But you can still do that with a non-interactive scheme. Work is still being done on this topic to create a secure k-of-n scheme which avoids rogue key attacks (which is the class of attacks you are describing).

You seem to think that we don't know that k-of-n needs more work to make it secure. You seem to think that we don't know that the participants want proof of the other participants. Well, here's the thing, we're not stupid. All of the stuff that you thought of are things that we already thought of and are working on ways of solving. It's not like MuSig is immediately ready to be used for all Bitcoin multisig transactions and that was never claimed to be the case.

If you read the paper, you'll notice in the section on Applications to Bitcoin, k-of-n is briefly discussed. In it, various schemes are briefly proposed that would avoid rogue key attacks but still allow for non-interaction and secure-ness. Things like just not doing key aggregation at all for an actual multisig or using merkle trees to prove the existence of keys.

I'm done with arguing with someone who refuses to even understand the technology he is arguing about. Back to my ignore list you go.
566  Bitcoin / Development & Technical Discussion / MOVED: hyperledger or ethereum? on: January 31, 2018, 01:42:17 AM
This topic has been moved to Trashcan.

567  Bitcoin / Bitcoin Technical Support / Re: Questions on - Signature aggregation and Lightning networks on: January 30, 2018, 01:51:47 AM
at $2+ per onchain fee.. it cost more then $4(2 channels) to set themselves up as a well connected peer to have more than 2 directions
It's cheaper if you open your channels in the same transaction, which, by the way, is possible.

Also, if you are a party in a channel, you don't necessarily have to fund the channel. One person can fund the channel, and the other person just has 0 balance in it initially. In fact, that's how the protocol currently works. So you could actually have many channels, of which many were not funded by you.

if an unbanked african guy (A) spend a weeks salary of $2 to set up a channel to B. if B refuses to accept A's lif savings of 10btc to be moved because B refused to handle such amount,.
Strange that he decided to setup the channel with B then because in the "lets make a channel" message, both A and B would have explicitly stated the terms of their channel. This includes the maximum amount that B is willing to transmit for A (and vice versa), the transaction fees to be paid in the commitment (can be updated later), who is funding the transaction, etc. All of this is done before any transactions are made so that A and B know exactly what they are getting into. It's strange that A would choose to open a channel with B if he knew that B would not be open to transmitting 10 BTC to someone else.

but.. for how long will this new peer X have 10btc 'available' to always be open to help A out
maybe X advertises having 10btc open to a hub... but X is also connectd to Y, Z and Y raided that 10btc before A got to use it
A can see what channels X has open, and he can see that X is also connected to Y and Z, as well as the hub. If he sees that X is advertising 10 BTC transmission, but has multiple channels open where he could, in theory, have more than 10 BTC attempt to be transmitted and his other channel only has 10 BTC, A might want to consider not opening a channel with X. Of course this would also all happen before any transactions are made.

Alternatively, A could not put all of his life savings in one channel. Instead he could open 2 or 3 channels using the same on chain transaction which might only cost him another 50 cents to open 2 additional channels. If he does that, he will be better connected and have more opportunities to be able to send his money.

achow.. lightning is not a infinite moneypot of money that is always open and infinitely usable.
I never said it was. What I am saying is that many of Lightning's detractors don't seem to understand how it works and like to ignore the fact that it's shown to be an improvement over the current on chain situation. This has thus far been shown on both mainnet and testnet where people are able to make payments that are way below the dust threshold and make payments to others in the network with little (on the order of single digit satoshis) or no fees.

stop thinking with the "i have to promote this" hat on.. an wear a "critical thinking" hat
I suggest you do that too. I am always wearing my "critical thinking" hat, but you never seem to be. It's always the "I have to shit on everything that Core does and everything that is not on-chain" that you seem to be wearing. I don't have to promote anything nor am I being paid to promote anything. Hell, LN is not even part of Core and we don't really have an interest in integrating it into Core. The people working on LN are completely different from those working on Core.
568  Bitcoin / Bitcoin Technical Support / Re: Can't get new Core client to recognize old wallet on: January 30, 2018, 12:53:09 AM
It installed and synced...but does not recognize my wallet.dat file (from my backup), has its own wallet file called Documents.dat
What do you mean "has its own wallet file called Documents.dat"? Bitcoin Core does not create a file called Documents.dat. The only way that would be created is if you have configured Bitcoin Core to create a wallet file named such.

What are the contents of your bitcoin.conf file?
569  Bitcoin / Development & Technical Discussion / Re: Elliptic curve point of R on: January 29, 2018, 10:21:08 PM
What do you mean by "original curve point"? Do you mean the generator point? If so, that's part of the curve parameters. You can only know that by knowing what curve you are using and its parameters. Given just a public key, you cannot know the curve parameters.
570  Bitcoin / Development & Technical Discussion / Re: Cascading Bitcoin Nodes on: January 29, 2018, 10:14:38 PM
I don't think a node will serve blocks to any other node until it is fully synced. So if your first node is not synced yet, you should wait for it to be fully synced and then try again with the second node.
571  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.15.1 Released on: January 29, 2018, 03:49:15 PM
Is there any different between bitcoin and bitcoin core? And how do I create account for bitcoin core?
Bitcoin is the name of the coin. Bitcoin Core is a full node software for Bitcoin. They are not two separate coins, but they are different things. You do not create an account for either Bitcoin or Bitcoin Core. You need a wallet, which Bitcoin Core is.
572  Bitcoin / Armory / Re: 0.96.3 Stuck scanning - 1 second forever on: January 29, 2018, 03:46:52 PM
Try using 0.96.4 RC3 available from here:
573  Bitcoin / Development & Technical Discussion / Re: MuSig: Schnorr Multisig and signature aggregation on: January 29, 2018, 01:27:05 AM
also known as a k of n multisig
this means that in a 2-of-5 multisig where 3 people dont have to sign,

as oppose to
interactive, where by its n of n, meaning it has to be a 5 of 5 or a 3 of 3 where everyone has to sign
No, that is not what interactive means.

In traditional cryptography, interactive means that the participants in the multisig must verify that the other participants actually control the private keys to their public keys, not that it is n-of-n. Non-interactive does not mean that it is k-of-n, it just means that there is no key exchange and verification protocol that must be executed.

Anyways, MuSig is specifically an n-of-n multisig scheme as it is a multisig scheme in the context of traditional cryptography.

this means when users see the funding public key, they dont know how many other signers there are or are needed in total
The same is with current multisig using P2SH. Hell, you don't even know whether a given P2SH address is multisig or not, so if you are a participant in any multisig, you should always be asking for the redeemScript, or, if using something based on MuSig, you should be asking for the public keys involved and make sure they calculate to the given aggregate public key.

and when the funds do move.. never get to know who specifically did sign

because the address doesnt tell them it is a 2 of 5..
because the address doesnt tell them who the other 4 people are

making it easy for whomever set it up to tell 3 guys its a 3 of 3 when in reality its a 2 of 5, and in reality whomever set it up owns 2 keys himself

so the 3 innocent guys dont realise its a 5 counterparty address.. all they can see is that their key is part of AN address.. but not know how much of a part...
This is completely incorrect, did you even read the paper or the linked blog post?

As I said earlier, MuSig is only a n-of-n scheme so this concern is completely invalid. To do k-of-n, additional work is required.

I don't quite get yet how the k-of-n threshold scheme comes in (maybe it's out of the scope of that paper?), but in general, this is great news. I hope a BIP detailing the actual implementation into Bitcoin will be forthcoming soon.
k-of-n is out of scope for the paper. MuSig is only n-of-n, but with additional Bitcoin specific things, can be done in a k-of-n fashion.
574  Bitcoin / Bitcoin Technical Support / Re: Lightning Questions on: January 29, 2018, 01:12:36 AM
I consider joining in and be #reckless. I have some design questions though. Under the premise that I mostly dont want to spend funds and want to help process transactions and establish cheap path's along the network. Currently the topology[1] looks to me like there are a couple main hubs and everyone else just attaches to them.
Currently the network is still fairly small. But if you look closely, the network is really not a hub and spoke network. Even if many people have channels with these "main hubs", many of those nodes also have channels with other nodes too. The "hubs" thing right now is probably because there are only a few services that accept LN on mainnet and people are just connecting directly to them in order to pay.

#1 (how connect?) What would be a good approach to establish alternative paths? Connect to all bigger hubs, e.g. all with x+ connections? Or rather establish a connection between other nodes within the network that are not already connected via a single hop?
I suggest you take a look at how LND does autopilot mode. It takes in various inputs and uses a model to figure out what channels are the bets to open. You can read about it in the release notes here:

#2 (resource requirements?) What (additional) resources are required? Has anyone data on this? I consider upgrading my server anyway, so this would be a good switching point.
LND does not need much more resources than those that are already required for running a full node (because you need a full node). You can also not run a full node and instead run it in SPV mode which uses BIP 157.

#3 (minimal funds/channel?) The current total capacity is only(?) ~3.68 BTC (again according to[1]), what would be - in your opinion - a good amount to put aside per channel? As much as possible obviously, but at which point does it become too little? Considering I plan to invest X amount of BTC this "minimal amount" would limit the number of channel I could reasonably keep open.
The current protocol limits channels to 2^24 (16777216) satoshis. There is no minimum funds; you can open channels or request channels to be opened where you provide no funds into the channel. IMO putting 0.01 BTC in a channel is reasonable.

#4 (is much work?) How much maintainance is needed? Funds would move between channels, but the main flow may be in a certain direction along the path. Because people just buy stickers instead of sending funds back and forth. Has anyone any experience with this yet?
At least on testnet, there doesn't seem to need much maintenance. The available software are capable of handling things automagically.
575  Bitcoin / Development & Technical Discussion / Re: c-lightning on testnet: problems and questions on: January 29, 2018, 12:57:59 AM
c-lightning coexists with bitcoin core whereas right now lnd doesn’t.
LND has the option to use Bitcoin Core as the full node backend.
576  Bitcoin / Bitcoin Technical Support / Re: BitcoinD RPC Server on: January 29, 2018, 12:49:59 AM
Thanks! For anyone else reading, I noticed that bitcoin-cli worked properly when bitcoind was invoked via the command line, but not when running the GUI.

Adding "server=1" to bitcoin.conf fixed this issue.
bitcoind will default to server=1. bitcoin-qt will not. So if you want to use the RPC server while running bitcoin-qt, you need to set server=1
577  Bitcoin / Bitcoin Technical Support / Re: Questions on - Signature aggregation and Lightning networks on: January 29, 2018, 12:48:38 AM
This argument relies on a model where the Lightning Network is in a degenerative case where it is a linked list and not a well connected graph. From current testing and use of the Lightning Network on both testnet and mainnet, we can clearly see that the Lightning Network is not this degenerative case and is instead a well connected graph. If a channel is chosen as part of a route going one direction, it can also be chosen for a similar transaction going the other direction, and that would re-balance the channel.

Furthermore, you can limit how much you allow in routes through your channels. So if B wanted to ensure that he still had money to pay C, he can refuse to route A's transaction of 10 BTC. A would instead have to find another route, which, given a well connected graph, is not very hard.
578  Bitcoin / Bitcoin Technical Support / Re: Dealing with Bitcoin hackers on: January 29, 2018, 12:39:24 AM
  • Redirect them to a file which contain a malware, a virus or an insult
  • Redirect them to a file which contain a script that will mess them (wait forever, hang their PC, etc.)
I would suggest that you not try these as those are things that can get you in trouble with the law. Well, having an insult is fine, but distributing malware is not.
579  Bitcoin / Development & Technical Discussion / Re: [LN] What is the typical payment channel expiration time? on: January 29, 2018, 12:35:51 AM

What you say changes my fundamental understanding of how LN works (or rather makes me think I don't really understand it).

From Wikipedia:

Isn't this transaction should be time-locked? I always thought about revocation as a spending hashlocked output back to myself while time-lock have not expired (if that makes any sense).

Also from here i get the impression that channel has limited lifetime (even though he speaks about unidirectional channel in this part I don't see how it's fundamentally different from bidirectional channels).
No, the revocation key is only used for the punishment transaction for broadcasting an old commitment transaction. The revocation key is only known after both parties in the channel have agreed to revoke a commitment transaction and replace it with a new, updated one.

The only thing with timelocks in LN are HTLCs (it's in the name) which are only used for routing payments to other people.
580  Other / Meta / Re: Can a newbie become a merit source ? on: January 26, 2018, 05:04:31 PM
Merit sources tend to be higher ranked and trusted members who have a history of making quality posts. A newbie does not have that history of quality posts nor are they trusted. Those come with time and experience. Thus it is unlikely that a newbie would become a merit source.
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 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 ... 547 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!