• Breaking News

    Friday, June 28, 2019

    Home Unlabelled Bitcoin Daily Discussion, June 28, 2019

    Bitcoin Daily Discussion, June 28, 2019

    June 28, 2019

    Bitcoin Daily Discussion, June 28, 2019

    Daily Discussion, June 28, 2019

    Posted: 28 Jun 2019 12:00 AM PDT

    Please utilize this sticky thread for all general Bitcoin discussions! If you see posts on the front page or /r/Bitcoin/new which are better suited for this daily discussion thread, please help out by directing the OP to this thread instead. Thank you!

    If you don't get an answer to your question, you can try phrasing it differently or commenting again tomorrow.

    We have a couple chat rooms now!

    Please check the previous discussion thread for unanswered questions.

    submitted by /u/rBitcoinMod
    [link] [comments]

    bought at $13,300 yesterday

    Posted: 27 Jun 2019 01:22 PM PDT

    Two types of Bitcoin investors

    Posted: 28 Jun 2019 01:04 AM PDT

    Nothing better than a dip right before payday

    Posted: 27 Jun 2019 12:03 PM PDT

    Technical: Upcoming Improvements to Lightning Network

    Posted: 27 Jun 2019 11:33 PM PDT

    Price? Who gives a shit about price when Lightning Network development is a lot more interesting?????

    One thing about LN is that because there's no need for consensus before implementing things, figuring out the status of things is quite a bit more difficult than on Bitcoin. In one hand it lets larger groups of people work on improving LN faster without having to coordinate so much. On the other hand it leads to some fragmentation of the LN space, with compatibility problems occasionally coming up.

    The below is just a smattering sample of LN stuff I personally find interesting. There's a bunch of other stuff, like splice and dual-funding, that I won't cover --- post is long enough as-is, and besides, some of the below aren't as well-known.

    Anyway.....

    "eltoo" Decker-Russell-Osuntokun

    Yeah the exciting new Lightning Network channel update protocol!

    Advantages

    • Solves "toxic waste" problem. In the current Poon-Dryja update protocol, old state ("waste") is dangerous ("toxic") because if your old state is acquired by your most hated enemy, they can use that old state to publish a stale unilateral close transaction, which your counterparty must treat as a theft attempt and punish you, causing you to lose funds. With Decker-Russell-Osuntokun old state is not revoked, but is instead gainsaid by later state: instead of actively punishing old state, it simply replaces the old state with a later state.
    • Allows multiple participants in the update protocol. This can be used as the update protocol for a channel factory with 3 or more participants, for example (channels are not practical for multiple participants since the loss of any one participants makes the channel completely unuseable; it's more sensible to have a multiple-participant factory that splits up into 2-participant channels). Poon-Dryja only supports two participants. Another update protocol, Decker-Wattenhofer, also supports multiple participants, but requires much larger locktimes in case of a unilateral close (measurable in weeks, whereas Poon-Dryja and Decker-Russell-Osuntokun can be measured in hours or days).
    • It uses nLockTime in a very clever way.

    Myths

    • No, it does not solve the "watchtower needed" problem. Decker-Russell-Osuntokun still requires watchtowers if you're planning to be offline for a long time.
      • What might be confused is that it was initially thought that watchtowers under Decker-Russell-Osuntokun could be made more efficient by having the channel participant update a single "slot" in the watchtower, rather than having to consume one "slot" per update in Poon-Dryja. However, the existence of the "poisoned blob" attack by /u/ZmnSCPxj means that having a replaceable "slot" is risky if the other participant of the channel can spoof you. And the safest way to prevent spoofing somebody is to identify that somebody --- but now that means the watchtower can surveill the activities of somebody it has identified, losing privacy.

    Disadvantages

    • Requires base layer change --- SIGHASH_NOINPUT / SIGHASH_ANYPREVOUT. This is still being worked out and may potentially not reach Bitcoin anytime soon.
    • Determining costs of routes is somewhat harder, and may complicate routefinding algorithms. In particular: every channel today has a "CLTV Delta", a number of blocks by which the total maximum delay of the payment is increased. This maximum delay is the maximum amount of time by which an outgoing payment can be locked, and needs to be reduced for UX purposes. Decker-Russell-Osuntokun will also add a "CSV minimum", a number of blocks, which must be smaller than the delay of an HTLC going through the channel. Current routefinding algos are good at minimizing a summed-up cost (like the "CLTV Delta") so the "CSV minimum" may require discovering / developing new routefinding algos.
    • Due to the "CSV minimum" above, existing nodes that don't understand Decker-Russell-Osuntokun cannot reliably route over Decker-Russell-Osuntokun channels, as they might not impose this minimum properly.

    Multipart payments / AMP

    Splitting up large payments into smaller parts!

    Details

    • There are at least three variants of multipart payments: Original, Base, and High.
      • Original is the original AMP proposed by Lightning Labs. It sacrifices proof-of-payment in order to allow each path to have a different payment hash. This is done by having the payer use a derivation scheme to generate each part's payment preimage from a seed, then having the split the seed (using secret sharing) to each part. The receiver can only reconstruct the seed if all parts reach it.
      • Base simply uses the same payment hash for all routes. This retains proof-of-payment (i.e. an invoice is undeniably signed by the receiver, including a payment hash in the invoice; public knowledge of the payment preimage is proof that the receiver has in fact received money, and any third party can be convinced of this by being shown the signed invoice and the preimage). The receiver could just take one part of the payment and then claim to be underpaid by the payer and then deny service, but claiming any one part is enough to publish the payment preimage, creating a proof-of-payment: so the receiver can provably be made liable, even if it took just one part, thus the incentive of the receiver is to only take in the payment once all parts have arrived to it.
      • High requires elliptic curve points / scalars. It combines both Original and Base, retaining proof-of-payment (sacrificed by Original) and ensuring cryptographically-secure waiting for all parts (rather than the mere economically-incentivized of Base). This is done by using elliptic curve homomorphism to addition of scalars to add together the payer-provided preimage (really scalar) of Original with the payee-provided preimage (really scalar) of Base.

    Advantages

    • Better expected reliability. Channels are limited by capacity. By splitting up into many smaller payments, you can fit into more channels and be more likely to successfully reach the payee.
    • Capacity on mutiple of your channels can be used to pay. Currently if you have 0.05BTC on one channel and 0.05BTC on another channel, you can't pay 0.06BTC without first rebalancing your channels (and paying fees for the rebalance first, whether the payment succeeds or not). With multipart you can now combine the capacities of multiple of your channels, and only pay fees for combining them if the payment pushes through.
    • Wumbo payments (oversized payments) come "for free" without having to be explicitly supported by the nodes of the network: you just split up wumbo payments into parts smaller than the wumbo limit.

    Disadvantages

    • Multipart will have higher fees. Part of the feerate of each channel is a flat-rate fee. Going through multiple paths means paying more of this flat-rate fee.
    • It's not clear how to split up payments. Heuristics for payment splitting have to be derived and developed and tested.

    Payment points / scalars

    Using the magic of elliptic curve homomorphism for fun and Lightning Network profits!

    Basically, currently on Lightning an invoice has a payment hash, and the receiver reveals a payment preimage which, when inputted to SHA256, returns the given payment hash.

    Instead of using payment hashes and preimages, just replace them with payment points and scalars. An invoice will now contain a payment point, and the receiver reveals a payment scalar (private key) which, when multiplied with the standard generator point G on secp256k1, returns the given payment point.

    This is basically Scriptless Script usage on Lightning, instead of HTLCs we have Scriptless Script Pointlocked Timelocked Contracts (PTLCs).

    Advantages

    • Enables a shit-ton of improvements: payment decorrelation, stuckless payments, noncustodial escrow over Lightning (the Hodl Hodl Lightning escrow is custodial, read the fine print), High multipart.
    • It's the same coolness that makes Schnorr Signatures cool. ECDSA, despite being based on elliptic curves, is not cool because the hash-the-nonce operation needed to prevent it from infringing Schnorr's fatherfucking patent also prevents ECDSA from using the cool elliptic curve homomorphism of addition over scalars.

    Disadvantages

    • Requires Schnorr on Bitcoin layer.
    • Actually, we can work with 2p-ECDSA without waiting for Schnorr. We get back the nice elliptic curve homomorphism by passing the ECDSA nonce through another cryptosystem, Paillier. This gets us the ability to do Scriptless Script. I think it has only 80-bits security because of going through Paillier though.
      • Basically the conundrum is: we could implement 2p-ECDSA now, hope we never have to test the 80-bit security anytime soon, then switch to Schnorr with 128-bit security later (which means reimplementing a bunch of things, because the calculations are different and the data that needs to be exchanged between channel participants is very different between the 2p-ECDSA and Schnorr). Reimplementing is painful and is more dev work. If we don't implement with 2p-ECDSA now, though, we will be delaying all the nice elliptic curve goodness (stuckless, noncustodial escrow, payment decorrelation) until Bitcoin gets Schnorr.
    • Elliptic curve discrete log problem is theoretically quantum-vulnerable. If we can't find a qunatum-resistant homomorphic construction, we'll have to give up the advantages (payment decorrelation, stuckless payments, noncustodial escrow over Lightning) we got from using elliptic curve points and go back to boring old hashes.

    Pay-for-data

    Ensuring that payers cannot access data or other digital goods without proof of having paid the provider.

    In a nutshell: the payment preimage used as a proof-of-payment is the decryption key of the data. The provider gives the encrypted data, and issues an invoice. The buyer of the data then has to pay over Lightning in order to learn the decryption key, with the decryption key being the payment preimage.

    Advantages

    • Enables data providers to sell data. This could be sensors, livestreams, blogs, articles, whatever.

    Disadvantages

    • There's no scheme to determine if the data provider is providing actually-useful data. The data-provider could just stream https://random.org for example. This is a potentially-impossible problem. Even if the data-provider provides a "sample" of the data, and is able to derive some proof that the sample is indeed a true snippet of the encrypted data, the rest of the data outside of the sample might just be random junk.

    Stuckless payments

    No more payments getting stuck somewhere in the Lightning network without knowing whether the payee will ever get paid!

    (that's actually a bit overmuch claim, payments still can get stuck, but what "stuckless" really enables is that we can now safely run another parallel payment attempt until any one of the payment attempts get through).

    Basically, by using the ability to add points together, the payer can enforce that the payee can only claim the funds if it knows two pieces of information:

    1. The payment scalar corresponding to the payment point in the invoice signed by the payee.
    2. An "acknowledgment" scalar provided by the payer to the payee via another communication path.

    This allows the payer to make multiple payment attempts in parallel, unlike the current situation where we must wait for an attempt to fail before trying another route. The payer only needs to ensure it generates different acknowledgment scalars for each payment attempt.

    Then, if at least one of the payment attempts reaches the payee, the payee can then acquire the acknowledgment scalar from the payer. Then the payee can acquire the payment. If the payee attempts to acquire multiple acknowledgment scalars for the same payment, the payer just gives out one and then tells the payee "LOL don't try to scam me", so the payee can only acquire a single acknowledgment scalar, meaning it can only claim a payment once; it can't claim multiple parallel payments.

    Advantages

    • Can safely run multiple parallel payment attempts as long as you have the funds to do so.

    Disadvantages

    • Needs payment point + scalar

    Non-custodial escrow over Lightning

    The "acknowledgment" scalar used in stuckless can be reused here.

    The acknowledgment scalar is derived as an ECDH shared secret between the payer and the escrow service. On arrival of payment to the payee, the payee queries the escrow to determine if the acknowledgment point is from a scalar that the escrow can derive using ECDH with the payer, plus a hash of the contract terms of the trade (for example, to transfer some goods in exchange for Lightning payment). Once the payee gets confirmation from the escrow that the acknowledgment scalar is known by the escrow, the payee performs the trade, then asks the payer to provide the acknowledgment scalar once the trade completes.

    If the payer refuses to give the acknowledgment scalar even though the payee has given over the goods to be traded, then the payee contacts the escrow again, reveals the contract terms text, and requests to be paid. If the escrow finds in favor of the payee (i.e. it determines the goods have arrived at the payer as per the contract text) then it gives the acknowledgment scalar to the payee.

    Advantages

    • True non-custodial escrow: the escrow service never holds any funds.

    Disadvantages

    • Needs payment point + scalar.

    Payment decorrelation

    Because elliptic curve points can be added (unlike hashes), for every forwarding node, we an add a "blinding" point / scalar. This prevents multiple forwarding nodes from discovering that they have been on the same payment route. This is unlike the current payment hash + preimage, where the same hash is used along the route.

    In fact, the acknowledgment scalar we use in stuckless and escrow can simply be the sum of each blinding scalar used at each forwarding node.

    Advantages

    • Privacy! Multiple forwarding nodes cannot coordinate to try to uncover the payer and payee of each payment.

    Disadvantages

    • Needs payment point + scalar.
    submitted by /u/almkglor
    [link] [comments]

    So be it...

    Posted: 27 Jun 2019 12:54 PM PDT

    40c per gallon discount. Using BTC @ Mobil is cheaper than local Costco Gas. La Jolla, CA

    Posted: 27 Jun 2019 08:35 PM PDT

    MRW I sold on the spike and re-bought on the dip

    Posted: 27 Jun 2019 03:43 PM PDT

    New? Scared? "80% crash. 'Bitcoin is dead' for 2 years. 250% parabolic rally in 1 month. Then, lost 40% in 1 week." < Look again... the chart below isn't dated "2019". When we say "we've been through this before", we're not exaggerating. HODL.

    Posted: 27 Jun 2019 10:55 AM PDT

    When you buy at the top

    Posted: 27 Jun 2019 01:35 PM PDT

    Dollar Cost Averaging Bitcoin

    Posted: 27 Jun 2019 08:19 AM PDT

    Everyone talking about the -20% drop but no one is talking about the +200% increase in volume.

    Posted: 27 Jun 2019 03:44 PM PDT

    PSA to newcomers: You are only at a loss, if you decide to sell at a loss.

    Posted: 27 Jun 2019 11:52 PM PDT

    Never sell at a loss. In the end, Bitcoin always prevails and crushes the previous high. Patience is key. Take advantage on red days like these and buy some Bitcoin. You will thank yourself later. Trust me. Welcome to Bitcoin!

    submitted by /u/MexicanRedditor
    [link] [comments]

    just spent my bitcoins for the first time!

    Posted: 27 Jun 2019 10:59 PM PDT

    I've been holding onto some bitcoin for over a year now, and today i finally used some to renew a VPN subscription - it was a really easy process and my transaction took just a few minutes to go through with a very reasonable 3% fee.

    Since I don't know anyone who would care to hear about this irl, I figured I'd post about it here to let you all know !

    submitted by /u/raphydaphy
    [link] [comments]

    Twitter CEO : Now you can withdraw AND deposit bitcoin, through @cashapp (this is my preferred small investor on-boarding tool)

    Posted: 28 Jun 2019 03:54 AM PDT

    Enjoy this bull run fellow HODL’rs, but don’t forget why we bitcoin! Save Humanity!

    Posted: 27 Jun 2019 03:17 PM PDT

    BTC mining in a mosque. Since electricity is free in mosques in Iran.

    Posted: 28 Jun 2019 04:23 AM PDT

    Edward Snowden - Bitcoin Conference 2019

    Posted: 27 Jun 2019 12:47 PM PDT

    What is a hardware wallet?

    Posted: 27 Jun 2019 11:50 PM PDT

    I am fairly new to bitcoin. I bought about half of one when it was around $3,500 early this year. I've been using coinbase as my digital BTC wallet but I recently learned about the ledger nano s hardware wallet. What is the benefit of having a hardware wallet like this and what can it do?

    submitted by /u/Jonnyjohnsonson
    [link] [comments]

    Just arrived ��

    Posted: 27 Jun 2019 08:51 AM PDT

    “If you locked me in a room, I don’t think I could design a more perfect macro environment for Bitcoin than what we have right now"

    Posted: 27 Jun 2019 05:38 PM PDT

    December 8-10, 2017 = 28% drop. It went to $19.5k 6 days later. HODL and chill.

    Posted: 27 Jun 2019 12:54 PM PDT

    I just got into Bitcoin monday

    Posted: 27 Jun 2019 06:22 PM PDT

    And this shit is for the birds. LOL! Wtf kind of ride did i just get on?

    submitted by /u/gillatron904
    [link] [comments]

    Fidelity's Cryptocurrency entrance to the market is almost ready. Their site is entertaining customers to contact them. *bonus point* check out their glossary of crypto terms. Check their wiki, they manage $2.6 trillion in assets. BTC marketcap just $250~billion

    Posted: 27 Jun 2019 12:35 PM PDT
    Read more
    at

    No comments:

    Post a Comment