Gold collapsing. Bitcoin UP.

[bitsko]

i'm not sure why people in control always take this position. or why you're the one here defending the donation. the BUIP suggestion is like the UASF; they say "we're going to do this whether you like it or not, and if you don't, you're free to go do a hard fork". as if that is a concession indicative of self reflection. or the responsible way to respond to disagreement. at least @Peter R should have solicited the opinion of the BU membership given that it's so divided. or at least be here explaining to members why he did what he did. what's with the radio silence? i could care less since i find it hard to be a BU fan these days and wonder why i step up so much to defend them when the officers don't even seem to want to do it themselves oftentimes.

Speaking of Peter R (god bless his work re:LN) I am completely opposed as a BU member to any funding given to Ledger Journal from BU.

I absolutely do not think he nor chris wilmer deserve a single bitcent from BU.

Ledger Journal should succeed (or fail) on its own merit.

 

[rocks]

Right. But I'm trying to get a feel for what that will look like. It's all free now because the blockchain is still fairly small and altruism is cheap. Storing data on the chain will bring the day of paid storage closer but it is fairly inevitable anyway. Bitcoin, as cash, doesn't really need the history, just the UTXO set (though it's certainly good to have that history available) and Satoshi himself described pruning of spent transactions.

I suspect once the costs of storing historical data become burdensome then full nodes (including miner nodes) on the BSV network will slowly switch to pruning historical data and operate with just the header chain and UTXO set. This was discussed earlier in the thread.

As that transition happens it will become harder over time for clients to find nodes that will return historical data. At that point there are economic incentives for others to run archival nodes (I discussed these earlier) which store and serve historical data for fees, probably on the order of what AWS and Azure charge for their data lake storage. Competition will be tough with all users looking for the lowest cost services and margins will likely be low with only the most optimal systems surviving.

We are a ways away from that transition though, even with the current 128MB limit I think it will be years before full nodes on the BSV network start to prune. The current node client SW does not even support pruning and operating with only headers and UTXO data yet AFAIK.

 

[Otaci]

Right. But I'm trying to get a feel for what that will look like. It's all free now because the blockchain is still fairly small and altruism is cheap. Storing data on the chain will bring the day of paid storage closer but it is fairly inevitable anyway. Bitcoin, as cash, doesn't really need the history, just the UTXO set (though it's certainly good to have that history available) and Satoshi himself described pruning of spent transactions.

Bear in mind that one of the strengths of Bitcoin is its balanced incentives (though we already see it has weaknesses when it comes to incentivizing development).

I phrased my answer that way because I just don't know. I'm sure that ingenious people will find all sorts of ways and I'm looking forward to being surprised.

One straight forward example would be a data provider service where you pay per tx retrieved, or per query executed. Maybe using a subscription model (boring) or a payment channel (cool). I could see this becoming a, possibly quite expensive, last-resort option, if you've lost your backups and need to file your taxes for example.

What might also happen is that various entities keep the portions they are interested in, or required to keep. For example, a stock issuer may be required to keep records for compliance reasons, but they'll only keep the tx they are interested in together with their merkle proofs.

A service provider may include it as part of their offering, for example an accountancy firm will keep your records for you.

So we might end up with a fractured space, where various entities keep the portions they are specifically interested in.

And finally, I'm sure some entities will keep all of it, they just might not want to share. Government agencies, research institutions.
[doublepost=1554919885][/doublepost]

We are a ways away from that transition though, even with the current 128MB limit I think it will be years before full nodes on the BSV network start to prune. The current node client SW does not even support pruning yet and operating with just headers and UTXO data yet AFAIK.

Bitcoin SV supports running in pruned mode and I know its being used. But I agree, its not really necessary yet.
[doublepost=1554920484,1554919738][/doublepost]Overlapped with @rocks post, some duplication, but I figured it would be better to leave it in.

 

[shadders]

Is MoneyButton open source?

How much funding did they receive since foundation? (I only vaguely remember investment by nChain and Bitmain being mentioned by Ryan before the fork...)

The BSV library that 90% of the ecosystem uses is open source and maintained by moneybutton.

Also I'd like to know how much investor funds cashshuffle has received if that question is on the table for donation recipients.

 

[Christoph Bergmann]

I phrased my answer that way because I just don't know. I'm sure that ingenious people will find all sorts of ways and I'm looking forward to being surprised.

One straight forward example would be a data provider service where you pay per tx retrieved, or per query executed. Maybe using a subscription model (boring) or a payment channel (cool). I could see this becoming a, possibly quite expensive, last-resort option, if you've lost your backups and need to file your taxes for example.

What might also happen is that various entities keep the portions they are interested in, or required to keep. For example, a stock issuer may be required to keep records for compliance reasons, but they'll only keep the tx they are interested in together with their merkle proofs.

A service provider may include it as part of their offering, for example an accountancy firm will keep your records for you.

So we might end up with a fractured space, where various entities keep the portions they are specifically interested in.

And finally, I'm sure some entities will keep all of it, they just might not want to share. Government agencies, research institutions.
[doublepost=1554919885][/doublepost]
Bitcoin SV supports running in pruned mode and I know its being used. But I agree, its not really necessary yet.
[doublepost=1554920484,1554919738][/doublepost]Overlapped with @rocks post, some duplication, but I figured it would be better to leave it in.

Going radically big blocks opens a lot of interesting questions and scenarios.

If miners compete for transactions, it could be a business model to validate and forward fresh transactions to miners, which pay for it. On scale full nodes have a share on transaction fees.

About data storage, I think you'll need to lock coins to keep it unpruned. Some way that returns can't be pruned if the corresponding value transaction is unspent.

 

[freetrader]

Real use cases being steadily unlocked on Bitcoin Cash. This one thanks to CDS.

Great work, Karol!

https://github.com/KarolTrzeszczkowski/Electron-Cash-Last-Will-Plugin

 

[Norway]

@freetrader
The Last Will smart contract is cool. Do you think it's impossible to make a similar service without OP_CHECKDATASIG?

 

[Richy_T]

As that transition happens it will become harder over time for clients to find nodes that will return historical data. At that point there are economic incentives for others to run archival nodes (I discussed these earlier) which store and serve historical data for fees, probably on the order of what AWS and Azure charge for their data lake storage. Competition will be tough with all users looking for the lowest cost services and margins will likely be low with only the most optimal systems surviving.

This here makes me a little skeptical about the idea of using the blockchain for data storage. If it's effectively locked behind a paywall anyway, you may as well pay a company or two for direct data storage and probably keep a copy yourself. Bear in mind that companies which host such a blockchain will also be hosting many other data dumps which nobody may ever be interested in using again and have the associated costs of that that they will have to pass on. I don't really see a great business case for storing large chunks of data that way. Smaller items, fine and hashes of documents for timestamping, it's great for those.

Now, I'm not suggesting any kind of restriction. If people are willing to pay the bitfee, they can stuff it with whatever they like. I just find it's not a compelling use to me.
[doublepost=1554946507][/doublepost]

One straight forward example would be a data provider service where you pay per tx retrieved, or per query executed. Maybe using a subscription model (boring) or a payment channel (cool). I could see this becoming a, possibly quite expensive, last-resort option, if you've lost your backups and need to file your taxes for example.

What might also happen is that various entities keep the portions they are interested in, or required to keep. For example, a stock issuer may be required to keep records for compliance reasons, but they'll only keep the tx they are interested in together with their merkle proofs.

I see this as a service that may well be built better on-top of the blockchain than within it. Something like bittorrent (which is closer to what you are describing), perhaps with the torrent hash stored in the blockchain. Perhaps there would be a way to say "Hash this file with this salt and if you can return me the hash I'm looking for, you can claim a fee" to encourage people to keep seeding.
[doublepost=1554946769][/doublepost]

Bitcoin SV supports running in pruned mode and I know its being used. But I agree, its not really necessary yet.

If this is pruned mode, it's not really the same as Satoshi style pruning. UTXO commitments are another thing that will change the space quite heavily.

 

[79b79aa8]

i went to BCT today to see what became of that place. i found that my old account (79b79aa8d5047da6d3XX) has been hijacked. some lowlife started using it on july 9, 2018. i abandoned it for good on august 1, 2017.

as the password was strong, i suppose the forum owners are appropriating dormant, full member or up accounts, and either selling them, or using them themselves to run sig campaigns (i.e. sell add space) and pump and dumps.

if you care enough, you might want to reset your password, at least to be certain, if you get squatted, that it wasn't via crack.

now some trivia, to lighten up: the old GCBU thread had 1558 pages + 59 in the original 'gold: i smell a trap'. in ~2 months this thread will have overtaken them. (20 posts per page all around).

cc: @Bloomie

 

[Zangelbert Bingledack]

That's what, over 50,000 posts of high-effort, high-economic-literacy discourse elevating the understanding of tens of participants and hundreds or thousands of readers, spanning 8 of Bitcoin's 10-year history?

We all have our differences, especially of late, but I want each of you regulars to know it has been a singular honor to post with you.

 

[cypherdoc]

i went to BCT today to see what became of that place. i found that my old account (79b79aa8d5047da6d3XX) has been hijacked. some lowlife started using it on july 9, 2018. i abandoned it for good on august 1, 2017.

as the password was strong, i suppose the forum owners are appropriating dormant, full member or up accounts, and either selling them, or using them themselves to run sig campaigns (i.e. sell add space) and pump and dumps.

if you care enough, you might want to reset your password, at least to be certain, if you get squatted, that it wasn't via crack.

now some trivia, to lighten up: the old GCBU thread had 1558 pages + 59 in the original 'gold: i smell a trap'. in ~2 months this thread will have overtaken them. (20 posts per page all around).

cc: @Bloomie

yeah, I made an announcement here in 2015 or 2016 that my BCT account had been hacked and no longer under my control. that multiple accounts appear to have been hacked makes me highly suspicious the theymos account was also compromised.

 

[shilch]

@freetrader
The Last Will smart contract is cool. Do you think it's impossible to make a similar service without OP_CHECKDATASIG?

The straightforward idea would be implementing ECDSA signature validation in script.
But you can also use nLocktime transactions to achieve some similar contract. The difference between the CDS and the nLocktime contract are that the CDS contract forces the refresher to send the coins to the same contract (address) on refreshing while in nLocktime the refresher is free to move the money; the other difference is that with CDS everybody can see the LastWill contract on refresh on the chain while with nLocktime the fact that an inheritor exists is kept private until the money is finally claimed by the inheritor (but even then it might look like any other nLocktime transaction).
[doublepost=1554961116,1554960148][/doublepost]

I see this as a service that may well be built better on-top of the blockchain than within it.

Bitcoin incentivises strong interconnectivity and fast propagation of data. If you build this stuff on top of the blockchain, i.e. you keep the data offchain, what is the incentive of a peer sharing the data with other peers? The peer should better keep the data private in order to be the only one being able to serve it.
It took me some time to understand the concept, the idea is that your bitcoin transaction is a data packet which I'll know that every other node will receive. The bitcoin tx fee is not a fee for storing data but for propagating it.

 

[torusJKL]

@torusJKL is this operational BUIP visible anywhere? I can't seem to find it.

Do you mean BUIP110?
It is here.

 

[Manfred]

i went to BCT today to see what became of that place. i found that my old account (79b79aa8d5047da6d3XX) has been hijacked. some lowlife started using it on july 9, 2018. i abandoned it for good on august 1, 2017.

as the password was strong, i suppose the forum owners are appropriating dormant, full member or up accounts, and either selling them, or using them themselves to run sig campaigns (i.e. sell add space) and pump and dumps.

if you care enough, you might want to reset your password, at least to be certain, if you get squatted, that it wasn't via crack.

now some trivia, to lighten up: the old GCBU thread had 1558 pages + 59 in the original 'gold: i smell a trap'. in ~2 months this thread will have overtaken them. (20 posts per page all around).

cc: @Bloomie

High ranking accounts get taken by forum owners. I lost my legendary account. Some get it back by providing all data ask for. I could not be bothered as the coin is done with anyway.

 

[Richy_T]

as the password was strong, i suppose the forum owners are appropriating dormant, full member or up accounts, and either selling them, or using them themselves to run sig campaigns (i.e. sell add space) and pump and dumps.

Chartbuddy got hijacked a while back. I'm not sure how I noticed as they hadn't done anything with it. I was able to lock the account but never went through the steps to recover it. I'm not sure how long ago you set your password but BCT has been hacked several times. Judging by some of the spam I've got, it seems about every public website out there has been lax with their security including some you would have hoped would have done better.

This site is interesting. It seems to be legit but you should look into things for yourself.

https://haveibeenpwned.com/
[doublepost=1554969208][/doublepost]

Bitcoin incentivises strong interconnectivity and fast propagation of data. If you build this stuff on top of the blockchain, i.e. you keep the data offchain, what is the incentive of a peer sharing the data with other peers? The peer should better keep the data private in order to be the only one being able to serve it.
It took me some time to understand the concept, the idea is that your bitcoin transaction is a data packet which I'll know that every other node will receive. The bitcoin tx fee is not a fee for storing data but for propagating it.

That's a fair point. Perhaps torrents aren't the best option unless the sharing can be incentivized somehow. That doesn't really reduce the issues with doing it on-chain though. propagating is incentivized but not for long. Once all miners have a copy of the block, the deed is done.

Interestingly, your objection actually applies here a bit too. Miners might be incentivized not to forward high paying transactions so they can claim the reward for themselves. Though in a well-connected network, this is not much of an issue.

 

[freetrader]

@freetrader
The Last Will smart contract is cool. Do you think it's impossible to make a similar service without OP_CHECKDATASIG?

No, just hella inefficient.

But I encourage you to do it on BSV, for the sake of storage and computation inefficiency.

p.s. spare me talk about optimization techniques using hardware and software that doesn't exist.

 

[79b79aa8]

now that's salty . . . the type of inefficiency involved is (i take it) computationally insignificant. and to complain about storage is, um, smallblockist. are such worries worth splitting the network? possibly not. mind you, i say this as someone who was all for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY.

 

[shilch]

unless the sharing can be incentivized somehow

The "somehow" is the issue, the way bitcoin incentivises propagation seems to be the only way to do this. Bitcoin is literally the solution to a lot of issues in p2p networks related to incentives - if it's allowed to scale.

Miners might be incentivized not to forward high paying transactions so they can claim the reward for themselves.

Yes, I hope that double spend orphaning as it has been proposed in the past can further incentivise propagation. But if you have a low fee/byte that shouldn't be much of an issue anyway.

i say this as someone who was all for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY.

I don't have any issues with these op codes either; though Nguyen et al might have a point that it has been introduced with the wrong intentions. The greater issue is constantly adding new opcodes to script. If it's allowed once for an opcode to be added without any reason, it will happen again. For every new opcode, all SPV wallets need to be updated. And if the opcode contains a bug/vulnerability (the one with medium severity in OP_DSV has been detected in time), it will have to be deactivated: Making all unbroadcast transactions containing that code invalid and remaining part of the protocol forever. In order to make script stable, Satoshi introduced the codes OP_NOP1-OP_NOP10 that allow implementing ten more opcodes at a later point without breaking old SPV software. As these codes have been introduced at the same time as OP_VER has been removed, she probably intended it as replacements for the existing crypto codes once the cryptography breaks.

 

[Peter R]

Is it within the power of the BU officers to donate BU funds to external projects without a vote by its members?

Yes, we have funds ear-marked both for "development" and "outreach." This project qualifies as both.

Further, there is precedent of BU giving small donations (typically under $5k) to projects that have requested help and are in-line with BU's mandates.

i guess. but then so does MoneyButton. i'd submit this has more to do with the position and ideology of the person making the donation as a general observation.

If MoneyButton asked for donations to help with something AND if the results of that something were open-source and so useable by the broader community, I'd be happy to assist with a donation.

 

[freetrader]

now that's salty . . . the type of inefficiency involved is (i take it) computationally insignificant. and to complain about storage is, um, smallblockist. are such worries worth splitting the network? possibly not. mind you, i say this as someone who was all for OP_CHECKDATASIG and OP_CHECKDATASIGVERIFY.

As I said, I encourage you to do it on BSV, for the sake of storage and computation inefficiency.

What's the holdup?