It’s more difficult than what it seems and as other said not in the spirit of decentralization
For lightning, you use your own keys, on your own wallet, on your own node. You can't get more decentralised than that |
|
|
|
|
Moving $1 trillion equivalent last year is not a delusion
Curious that Buffet would make these comments at a time when Berkshire Hathaway are reporting failures. Sucks to be him right now.
|
|
|
|
On-chain, at least, Bitcoin clearly handles a smaller number of transactions compared to PayPal. But the BTC transactions are worth more in USD. Which is mainly the result of BTC's dollar price rising over the years. Throughput is increasing on-chain with more companies batching transactions To me, that's a list of significant reasons why comparing Bitcoin's transaction volume to Paypal's isn't particularly meaningful; Paypal doesn't have at all the same technological challenges in handling high transaction volumes, as it's a mature centralised network. Lightning has the potential to surpass Paypal's tx throughput, but we'll never have actual measurements as to whether that's happening in practice, because of the private nature of the payment channels on Lightning. So this metric is at least something we can make definitive statements about, and it's very positive for Bitcoin's outlook. |
|
|
|
This new platform will be implemented first by the Bank of China.
Presumably, that means any properties bought using this network would be in China. You'd have to be completely out of your mind to even consider such a thing (but you'd be somewhat out of your mind to use a blockchain based property blockchain in the first place. I hate to be the biggest cynic in a thread, but this could easily be a fishing expedition for cryptocurrency holders) |
|
|
|
How is this possible? No Lightning without a malleability fix. Schnorr sigs are inherently non-malleable, or at least sigs using the schnorr implementation that Bitcoin Core devs designed (and Bitcoin Cash devs copy-pasted) are In other news, Toomin is apparently thrashing around trying to get a tiny percentage improvement in block propagation over BIP152 compact blocks (now ~2 year old tech). Such innovate. |
|
|
|
HostFat managed to be so wrong about so much, in this hilariously not-aging-well assertion of his favorite controversial hard forks' superiority.
Unlimited, XT, and Classic are abandonware now, while BAB and BSV are notorious for their conflicts of interest created by the very rich people known as Roger Veer, Jihan Woo, and Calvin Airhead.
 Even funnier: what's the latest tech addition to Bitcoin Cash in their May fork? Lightning. And whose (unfinished) work did they copy & paste to make Lightning possible on Bitcoin Cash? Bitcoin Core's Schnorr sigs spec. |
|
|
|
|
Tim Draper knowingly bought stolen Bitcoin to get into the market, so that's a bit of a questionable statement
|
|
|
|
It's a first step, and very likely a step that's meant to test the functionality and reliability of Bitcoin in this case. In other words, I'm actually quite happy with articles like these.
The trouble is, the wording in the article is a bit non-specific. It could easily have been contractors paying each other, not the actual Paraguay-an/Argentinian governments. What if it was the payments contractors of the service contractors that did this $7000 deal? Or the cross-border payments contractors of the payments contractors of the service contractors? |
|
|
|
- Schnorr permits signature aggregation, that treats the sum of >1 signature as a single valid signature for more than 1 transaction
So multiple concepts get confused here, so I can't tell exactly what you're talking about. There is signature aggregation which combines signatures from multiple inputs (but probably just one transaction) in to one  s/transaction/input/ or efficient threshold signatures which allows many signers to produce a single signature for a single input.
Both make signatures in transactions much smaller, so don't justify any change in how weight is computed. Multisig schnorr allows sig aggregation too, forgot about that. - Taproot will allow conditional branches in more spending scripts to be collapsed into a Merkle root hash for all branches, so only the condition that is met is ever recorded on the blockchain
This directly makes transactions much smaller, so again, no need to change how weight works. Yes, it makes the cold cache catchup case spend half the time in signature validation. (non-catchup doesn't do validation in the critical path due to caching! --- the small batching you can do as txn come in doesn't get much speedup) Ahhhh, I didn't retain that from BIP-schnorr either, batched validation depends on a certain amount of cached signatures to work. I assumed that individual blocks were the unit of resolution at which batching would happen, as the batching performance graph shows 2-2.5x improvement at ~2500 transactions, which is a rough average of maximum transactions per block. The eventual speedup from batching (and the speedup we achieved from caching in the non-catchup case) was part of the justification for having witness data have lower weight to begin with.
With the exception of batching the other advantages you cite already result in lower weight (in the cross input case, much lower weight). So they're naturally already awarded.
Sure, but my point is that although batching doesn't affect the total number of signatures to validate, it does incentivise the same thing that weight differentiation does (validation performance). Really, the other changes I cited don't alter the weight per sigop, simply the aggregate weight of (of course this can make a huge difference to the total number of sigops per block) Different users experience different pain points, some are cpu limited, some are bandwidth limited, some are power limited, some are storage limited. Many are some mixture of multiple of these. Because of this no single weight formula can be optimal. What really matters is that it sets the incentives in the right general direction, in order to break ties in the favour of public interest.
Generally we can assume that in the long run most users are going to do whatever is most cost effective for them. If foobar signatures were a LOT better for the network it would still be sufficient that they be only slightly better for the end user, even if making them much better would be justifiable under some cost model... even a little better will get them made a default. Some users will have different motivations and make different choices, but a small number of exceptions is mostly irrelevant for the overall network health. This is important, because a perfect balance isn't possible. E.g. with weight, you could easily argue that an 8:1 ratio or a 16:1 ratio would have been better-- but a higher ratio means a LOT worse worst-case bandwidth, and so wouldn't be good trade-off for those users who are bandwidth limited. The fact that the only "direction of incentive" needs to be right, not so much the magnitude, means its possible to make compromises that give good results for everyone without screwing over some cost models. That makes sense. I'm still interested in an argument why improving (future) IBD by up to 2x shouldn't lessen weight assignment per schnorr signature (regardless of how many signatures or script hashes are aggregated together). You're essentially saying that the witness discount was formulated to price any signature scheme, no matter it's validation performance? |
|
|
|
|
Brock Pierce was hanging out with convicted paedophiles in Spain, just him and his 2 convicted paedophile buddies. They are all 3 connected to the paedophilia case involving former Hollywood director Bryan Singer, where aspiring teenage actors were invited to get drunk and high at Singer's mansion
Anyone giving Brock Pierce any kind of airtime is knowingly endorsing a man that happily witnessed these events and continued to be involved with convicted paedophiles. Max Keiser is hence a very questionable character indeed.
|
|
|
|
that software should come with a health warning... From the bitcore.io front page: Bitcore uses the source code of Bitcoin directly, so accidental chain forks are a thing of the past. Right, except when Bitpay change the underlying source code to switch you to a different chain fork, deliberately. At least Bitpay tell you they do this kind of thing, they tell you "bad things will happen" if you don't use the software that uses the chain fork they think you should use. Unless you want to constantly check how Bitpay are imposing their self-interest on the code you run, you're better off choosing a solution that you can rely on permanently. Or fork their API and patch it into the Bitcoin source code, then you can be compatible with the API and use trustworthy source for the bitcoin network (assuming the API does the job you want) |
|
|
|
So the rationale for introducing transaction weight is to put a separate price on signature operations, to reflect the resources sigops use when running a fully validating node (i.e. a price component for block space and a price component for sigops when determining tx fee). Should this be reflected in the weight value assigned to transactions using schnorr sigs in the future? Using schnorr sigs already reduces the proportion of a tx comprising the signature: - BIP-schnorr defines a standardised 64kB size, smaller than the typical ECDSA sig size (71-72kB)
- Schnorr permits signature aggregation, that treats the sum of >1 signature as a single valid signature for more than 1
transaction tx input - Taproot will allow conditional branches in more spending scripts to be collapsed into a Merkle root hash for all branches, so only the condition that is met is ever recorded on the blockchain
All the above reduce the space that signatures use on chain, and sig-agg can reduce the number of sigops used drastically for transactions with multiple inputs. But batch verification works across an entire block of transactions, which would improve verification performance ~2x according to BIP-schnorr. That would make far more difference to validation performance than any of the points above, as it functions whether using sig-agg/taproot or not (and the 64kB size reduces space on chain, not sigops). My question is: to incentivise the gains for the network, should schnorr sigs be assigned a lower weight than ECDSA sigs? It seems to make sense, given how much validation performance can be realised. |
|
|
|
If I rebuild the database to fix this will I lose my bitcoin?
No. But back the wallet files up anyway. Did you not backup when creating the wallet? Armory basically forces you to backup at the same time you create a new wallet |
|
|
|
|
It was ostensibly a small (~$7000) deal. It's slightly desperate as a news item, that kind of sum is a mediocre deal even between individuals, let alone larger organisations.
|
|
|
|
is there any bitcoin developer besides luke that's interested in doing this?
Nope: That was the old thing, but apparently on twitter he's talking about something even less reasonable now.
In any case, I showed this thread to other developers and the response was uniformly a big wtf.
|
|
|
|
-maxconnections= Maximum number of inbound+outbound connections?
if you are running a full node could you please check and say?
ok, so i checked and it's actually the total maximum, inbound + outbound. Using -maxconnections=1 will connect 1 outbound peer, 0 inbound peers sorry for any confusion, but that's how Bitcoin Core 0.17.1 handles it |
|
|
|
8 in, 8 out
Is this true? Need someone to verify this probably. link + text quote on the 2nd post of this thread |
|
|
|
- Old ASIC hardware
- The use of old motherboards and graphics cards
- Searching through scrap hard drives.
None of those will be compatible with the interests of the mining elite here.
They're also almost certainly a waste of effort, or money at least. If every thread like that stayed on the main mining sub-boards, the information that's actually contemporary/relevant could get drowned out. There's always been someone turning up asking questions they could find the answer to by searching. That being said, if there are people that want to engage in that kind of thing anyway, maybe a "Mining Newbies" board would be a good idea, although I predict it would turn into a bit of a swamp fairly fast |
|
|
|
I stopped reading anonymint's blog when I saw that he posted this image, comparing the "transaction speeds" of different blockchains.  It's easy to trick the newbies to believe that the other "blockchains", Ripple for example, is faster without context. He is full of shit. If you believe context is important, you should pay attention to the size of the image you linked to. The image is currently huge, and your explanatory text comparatively very small |
|
|
|
What does maxconnections=8 means? 8 in, 8 out The answer is 1 post before your first post in this thread (quoted from the bitcoin.stackexchange.com link) |
|
|
|
|
Show Posts
