In my opinion there's little difference between using an exchange to automatically convert to a stablecoin and using a payment provider like BitPay to convert to fiat.

Both requires trusting a third party and contains counterparty risk. Converting to a stablecoin seems more like an unnecessary extra step at this point (unless you then want to convert from the stablecoin to another digital asset of your choice).

There's a bunch of decentralized stablecoins, it's just that none of them appear to be fully reliable:
https://bitcointalk.org/index.php?topic=3421190.0

Honestly I think that's the main issue at heart here -- the challenge of creating a reliable, decentralized stablecoin. The irony being once we'd solve that issue, we wouldn't need hedged Bitcoin invoices as described by OP to begin with. We'd just use the stablecoin itself.

Unless there's a decentralized stablecoin being swapped I have to agree with ETFbitcoin that this seems like you'd merely swap a centralized payment processor for a centralized stablecoin issuer. Even so I think it would be an interesting addition to our ecosystem. Whether there'd be a large enough market for those swaps to work reliably is a different question though.

What about the time window for penalty transactions though? Shouldn't the time window of one week for broadcasting a penalty transaction in case of a would-be attack be enough for someone who isn't online 24/7? Or has this been proven unreliable?

Just curious since with all the talk about Watchtowers this part of the protocol has been spoken less and less about.

The block interval of 10 minutes was probably simply a very conservative guesstimate.

Keep in mind Bitcoin was pioneering the field, it then took the first generation of alts to tinker with the basic parameters to see what works and what doesn't. Turns out Litecoin's block interval of 2.5 minutes works just as fine. Some alts reduced their block interval into the tens of seconds or even less with... not so good results. Orphan rate becomes a real problem at that time scale and needs to be dealt with (e.g. Ethereum paying subsidy for uncle blocks), otherwise your coin will be quickly forgotten.

Also you gotta think ahead a bit -- between Earth and Mars you have a data roundtrip time of 6 to 9 minutes!



That's just a sneaky way to increase blocksize

Interesting paper. While I wonder how easy it is find suiteable routes for DoSing LN in practice I guess we'll see soon enough now that this paper has been released.

It's also always nice to see a paper that ends with proposed solutions that do not include an attempt to push a new pre-mined alt coin. Also mitigation seems to be mostly tweaking some parameters with existing LN implementations and safeguards that seem relatively straight-forward to implement -- eg. loop avoidance, as mentioned in the paper -- so we're not utterly doomed yet. It goes to show that we're still in early stages though.

I don't follow Bitcoin's testnet closely, but I assume it's because the difficulty drops back to 1 whenever no block has been found for 20 minutes [1]? At least that would explain testnet's block height of beyond 1.6M [2] which means it already went through 7 halvings which would correspond with the block subsidy mocacinno mentioned.

[1] https://en.bitcoin.it/wiki/Testnet
[2] https://live.blockcypher.com/btc-testnet/

Yep. Timelocking a transaction only ensures that the timelocked transaction itself won't be accepted before the end of the timelock. You can still spend the very same coins in other transactions. That's why you can use them as part of a Dead Man's switch setup, for example.

Also, I wouldn't rely on the mempool alone to prevent double-spending. If that's all it took we wouldn't need a blockchain.

Also, mempools don't stick around forever. A timelocked transaction that's not being added to the blockchain, will get removed eventually. To make matters worse each mempool keeps transactions around for different timeframes. So the "channel state" will quicky diverge over time as mempools diverge.

Come to think of it, I'm not even sure whether a not-yet-spendable timelocked transaction is guarantueed to stick around the mempool in the first place.

Ich glaube das fragwürdige Mantra auf das sich qwk bezieht ist eher:


Zumindest wäre dass das Problem das ich mit dem Ansatz sehe.

Ich mein, klar, z.B. Luxemburg hat dank niedriger Steuern immense Steuereinnahmen. Aber das sind weder indirekte noch durch wirtschaftskatalytische Prozesse bedingte Einnahmen.

First of all, because you don't want to cut it too close. A PSU running at or beyond full load is a PSU with a short lifespan that may turn into a PCB BBQ sooner rather than later.

Secondly, most PSUs reach peak efficiency at a load of 40%-60%:
https://www.corsair.com/br/ja/blog/how-to-build-a-pc---the-power-supply

The closer you get to 100% load, the more efficiency plummets. The lower the efficiency of your PSU, the more you're needlessly spending on electricity. The less profitable your mining rig.

Tatsächlich gabs da bereits 2018 einen Gesetzesentwurf welcher die Besteuerung geändert hätte:
https://bitcoin-austria.at/de/artikel/steuern-bitcoin-privatvermoegen-aenderung

Anscheinend dürfte das Ganze dann zum Glück in klassisch Österreichischer Manier versumpft sein. Würd mich allerdings auch nicht wundern wenn das Ganze dann (in ebenfalls typisch Österreichischer Manier ) von Heut auf Morgen im Sommerloch doch noch zum Gesetz wird. Das geht dann manchmal doch recht zackig.

Bzgl. Aktien darf man allerdings auch nicht vergessen dass es da diese Regelung mit Alt- und Neubestand gibt (bzw gab). Also Wertpapiere die vor der Gesetzesänderung gekauft wurden konnten/können steuerfrei veräußert werden. Mit Kryptowährungen müssten die dass dann konsequenterweise ähnlich lösen.

Connectivity, resilience and verification.

If only mining pools where to run nodes they could be relatively easily isolated from the rest of the network, be it by accident (e.g. large to mid-scale network outages) or by malicious intent (e.g. DDoS attacks, governmental interference). One effect of this would be a higher orphan rate (ie. miners forking of the main chain by accident), leading to (1) decreased security due to less effective usage of hashing power and (2) decreased reliability of confirmations due to higher risk of chain splits and reorgs. Especially the latter has significant practical implications since low confirmation transactions would be prone to "disappear". Also, bluntly speaking, it's easier to block a few dozen servers rather than a few thousands.

Apart from why the network profits from having as many nodes as possible it's more secure to run a node of your own if you process a lot of transactions (eg. as a merchant, payment provider or currency exchange). Rather than having to trust a third party on what they say what the blockchain looks like, look for yourself. Or as the old adage goes: Don't trust, verify.

Sooo... an Elliptic-curve Diffie-Hellman key exchange over the Bitcoin blockchain?

I think this paper describes pretty much what you are suggesting, maybe it's of interest for you:
https://eprint.iacr.org/2015/308.pdf

I'm not aware of any implementations being used in practice though. Something related was suggested in the form of ECDH addresses a while back:
https://en.bitcoin.it/wiki/ECDH_address
https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki

@OP: Getting in touch with LocalBitcoins support as mentioned by jackg and 20kevin20 is your only bet. Unfortunately it's likely to be rather costly as most exchanges charge retrieval fees in the hundreds of dollars (assuming they offer retrieval at all).



I guess they are alluring to nested P2SH SegWit's anyone-can-spend outputs?

Sending BTC to P2SH BTC SegWit -- those coins are safe. Any attempt to "claim" these coins would result in a (soon-to-be-orphaned) fork that will be ignored by all other BTC nodes and miners as enforced by SegWit rules (ie. according to SegWit rules such a transaction would be invalid).

Sending BCH to P2SH BTC SegWit -- that's an interesting case. Since there are no SegWit rules to follow those coins truly are anyone-can-spend so are up for grabs by anyone, not just miners. It's just that a miner would be stupid to not claim those coins for themselves, the only competition being other miners (ie. there are no SegWit rules so such a transaction would be valid).

In terms of how it looks in the protocol:

The transaction fee is the difference between the inputs of a transaction (ie. the amount that leaves the sending addresses) and the outputs of a transaction (ie. the amount that arrives at the receiving addresses).

They can be claimed by a miner by adding the transaction fees amount to the block subsidy amount and sending the whole sum as output to their receiving address.




It's worth noting that there's no distinction between miners and nodes on the protocol level (at least if I recall correctly). While the people running mining hardware do not necessarily run their own node, the mining pool that they are directing their hashpower at will. It is this node (or nodes) that will then broadcast the blocks as built by the miners.

So from a protocol point of view they are all just nodes -- it's just that some find new blocks (miners) and some don't.

Pretty much this. The network can't know in a reliable and tamper-proof way whether there's "enough" transactions floating around.

Additionally enforcing a mininum block size would just artificially slow down the network when there's not much going on (ie. due to miners waiting for enough transactions to fill their mempool before building a block) while doing nothing to increase transaction throughput when blocks are full.

Also note that as block subsidy gets reduced over time, transaction fees gain in importance. Currently the block subsidy still surpasses the profit made by fees, but once fees are the main income there's literally no profit to be made from creating empty blocks.

Note to any newcomers reading this: The site posted above has been around for less than half a year (ie. has yet to build a reputation), so be careful. Then again SafeDICE has been around for a couple of years before it went AWOL so... ¯\_(ツ)_/¯

Nice looking site though, will definitely keep an eye on you!

As pointed out by hugeblack most of these services are not yet established, so caveat emptor! Same even goes for already established sites like Bitfinex, unfortunately.

Either way, I got another addition for your list -- Bitstamp:
https://www.bitstamp.net/lightning-network-node/

Stats as of writing:

From the looks of it this halving countdown doesn't take hashrate growth into account, so you might be lucky

98 days (as of today) is what you get when you assume the average 144 blocks per day to be true. While difficulty should adjust every 14 days (ie. every 2016 blocks) continous hashrate growth can lead to more blocks being mined towards the end of a difficulty period until difficulty re-adjusts (the opposite is true when hashrate declines).

So for the last few cycles the average blocktime was closer to 09:30 rather than 10:00:
https://btc.com/stats/diff

Leading to an average of 151.5 blocks per day.

As of right now there's still 14,212 blocks left to the next halving, which means adjusting for 151.5 blocks per day would put the next halving in 94 days, ie. on the 8th of May rather than the 12th. The 8th of May would be a Friday, so keep your fingers crossed that the Bitcoin network keeps growing the way it has for the last few weeks Or maybe that growth slows down just a little bit, as to put the halving on a Saturday.

After seeing the occasional thoughtless newbie post about combining blockchain with machine learning (who cares about details as long as we put buzzwords together amirite?) it's nice to finally see something with a bit more substance.

What bothers me a bit is that the concept of PoUW seems to be more like a red herring, with the actual security coming from a PoS system trying to keep participants honest. That is on top of what odolvlobo posted regarding PoW requiring "useless" work for security.

Their treatment of Sybil Attacks also looks a bit hand-wavy to me. Disallowing nodes to pick their own tasks might work if you only have a limited number of bad actors; I have my doubts that this would be effective enough in a more serious scenario.

Either way I still need to dig a bit deeper into that paper. Thanks for sharing!