Bitcoin Forum
May 24, 2024, 08:19:56 PM *
News: Latest Bitcoin Core release: 27.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 »
81  Bitcoin / Development & Technical Discussion / Better than POS. Proof of Virtual Work. on: June 19, 2018, 12:05:54 PM
I did have a thread about this about 2-3 years ago..  can't find it..

You have a Dual Coin chain. One is the currency, and one is the mining tokens.

You buy/sell mining tokens on chain with the currency and those give you the right to mine blocks, more mining tokens, more blocks you find. Block fees are paid in the currency.

The issues with POS that this fixes..

1) All those who own mining token WILL mine (or be penalised if they fail to find a block when it's their turn), so you will have ~100% staking power, rather than the usual 15-20% you get on a POS coin. Small holders of POS don't mine, and as they make up a majority (or should), this leads to low percentage of stake holders mining - thus making attacks cheaper. (I know exchanges have most of the coins anyway, but at some point this shouldn't be the case)

2) Decoupling mining power and stake.. means you don't end up with any entity having an unassailable lead, as a 51% POS holder has. You don't need to be the top stake holder to be the top miner - or vice versa.

You still have nothing at stake.

The lure of low energy consensus is strong, and I do hope that someday someone fixes the NAS issue. (Reverse Stellar Based Check-Point Holes?)
82  Bitcoin / Development & Technical Discussion / Re: How to prevent 51% ATTACK on new coin on: June 19, 2018, 09:45:45 AM
You could do what IOTA does. Have a 'Coordinator'.

Basically it's a centralised server that Timestamps the CORRECT chain. You run it on your servers (users check with you), and you refuse to re-org past 1 hour, no matter the weight of the other chain. Totally not cool in the long run, but in the Bootstrap period of a coin, I don't see any issues.

This is only temporary ( or so they say on IOTA, but I have my doubts ), and once your hash rate is high enough you can get rid of it.
83  Bitcoin / Development & Technical Discussion / Re: Is POW systematically doomed to get a huge monster in its midst? on: June 18, 2018, 09:41:01 AM
.. snip ..

Aaahhhh.. AnonyMint. Your ability to reincarnate has activated again I see.. (I count 5 lives left) In all honesty, I cannot deny I've missed some aspects of the intellectual brutality of your posts. Still as batshit-cray-in-your-face as ever though. 

.. but if their prognostications of mass-theft were to come true

Best word!
 
---------------------------------
Back to the original topic
---------------------------------

I think not. The problem is not POW. Pow as an objective un-fakeable work unit is genius. The problem is that we PAY people to accumulate POW. Centralisation is pernicious. It creeps in, slowly at first.. until it's too late.

The DAG coins have flaws, sure, but in this respect they have removed the elephant in the room.

I believe 1 Billion users could outpace a cartel, if they were mobilised in the correct way. 

Someone just needs to come up with a way of doing it (that doesn't involve some other centralised entity stitching the disparate parts together).
84  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 15, 2018, 02:19:09 PM
Also, that also risk the user who withdraw their bitcoin with less than 100 confirmation when the hacker take over exchange's wallet/private key.

No..this is exactly the point. the exchange only ever keeps the R-ON key online. This is no problem.

The R-OFF key is NEVER online. Only ever used AFTER a hack.

This way you get cold storage security, with hot wallet convenience.
85  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 15, 2018, 02:10:17 PM
That also means exchange's user need to be cautions when their bitcoin withdraw have less than 100 confirmation.

It's not there's yet. They can't touch the coins for 144 blocks. Again - this is only for LARGE HOT WALLETS.

If the user wish to send their bitcoin to another person, they also need to wait for 100 confirmation.

Once the User has waited 144 blocks, those coins are _then_ his, and behave like regular normal coins.

I'm not saying ALL coins should use this, but it's certainly a very handy way of securing certain situations.

You could choose. You want to have your coins stored by the exchange in their R-Address (probably insured too..), and wait 144 blocks before getting your withdrawal (which you can then use as per usual), or.. not use the R-Address and risk theft, but get your coins quicker when you withdraw. Up to you.
86  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 15, 2018, 12:51:10 PM
Anything with the word "reversible" in Bitcoin should make your alarms beeping automatically.

Absolutely, but this situation is very different.

These addresses would work great for Large Online Hot Wallets.

Like an exchange.

In practice - it just means they don't send the user their coins directly. They send them first to the special safe-house address, the S-Address. And once there, the user can come and collect them. Then he can consider the coins his. Not before. No one is reversing anything.

If the coins are taken maliciously, the exchange can just retrieve them from the safe-house, before the malicious user can.

Obviously - if the R-OFF key is stolen, all bets are off. Hacker would then have root. But the R-ON address could certainly be kept online, with no real security issues.
87  Bitcoin / Development & Technical Discussion / Re: How strong is Bitcoin against 51% attack ! on: June 15, 2018, 12:38:38 PM
When accepting payments below $1 million dollars.. no one is going to 'Attack-The-Chain'. As you say, too expensive.

When accepting payments over $1 million, just wait a little longer..

If you did have 51% hash power, outrunning a 1 day chain, takes.. Yep.. 50 Days. No ones going to do that. (You only get a 1% boost - as the normal chain grows as per usual, but slower..)

I think to properly attack the network, what you need to do is remove 90% of the hashrate. But probably only a government could do that.. or BitMain (root kit) LOL..  China could just shut all the Chinese miners down. If you could do that, BTC would be in trouble. The blocks would take f-o-r-e-v-e-r-.. the retarget period would take 100's of days. You could hard fork your way to a simpler difficulty, but that's the only way. (But then I suppose they could turn the machines that go PING back on.. and attack properly.. with 90%..)

Anyway, I'd like to see a system introduced that could handle that sort of hash rate loss. Simply allowing the difficulty to trail off after 2 hrs.. has security issues..

It almost happened when BCH attacked the network.

..

The only people who could even think of doing this are those we pay to protect us.  Always the way (when you pay a third party to protect you).
88  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 14, 2018, 09:10:02 AM
Thinking more on this..

It can all be done with Covenants. ( This is a script feature that allows you to specify conditions for which addresses an output can be spent to.. )

https://blockstream.com/2016/11/02/covenants-in-elements-alpha.html

A future feature..

89  Bitcoin / Development & Technical Discussion / Re: If you just SUM the inverse-hashes of valid blocks ..? on: June 13, 2018, 06:42:34 PM
P2Pool uses a system a little bit like this.

In P2Pool, you search for a block every 10 secs. You publish at that difficulty level, on the P2Pool network. BUT if you find a block that is 60x harder (one every 10 minutes), enough to be a valid Bitcoin block, you then publish that on the mainnet. The cumulative POW is preserved  - in a smaller amount of blocks.

In this scenario using multi-difficulty blocks has a great use case. 

I am trying to leverage this.

In Bitcoin, you search for a block every 10 minutes. You publish at that difficulty level, on the mainnet. BUT if you find a block that is 60x harder (one every 10 hours), enough to be a valid Super Block (let's say), then you can publish that on a Super Block Network, where you only find one block every 60 normal Bitcoin blocks. The cumulative POW is preserved - in a smaller amount of blocks.

The point is that since this works for dual-difficulty blocks, what happens if you take this to the extreme, and simply use the inverse-hash as the block weight ?

It STILL seems to work (chain with most POW wins), but the fluctuations are far bigger..

I'm trying to see if those fluctuations can be better controlled.
90  Bitcoin / Development & Technical Discussion / Re: If you just SUM the inverse-hashes of valid blocks ..? on: June 13, 2018, 02:33:01 PM
Sometimes miners mine blocks with a hash quite a lot lower than the target value

And that is exactly the problem, since such unexpectedly low hashes will then cause multiple blocks to get orphaned. There will be a permanent state of uncertainty about finalization of recent transactions.
6 confirmations will no longer be particularly safe.

For the same reason, this will make selfish mining all the more effective.

So the Longest Chain Rule, where one next block is as good as any other, is quite essential in stabilizing the transaction history.

Yes - this is the issue.. one lone hash can wipe out many normal / smaller hashes.

I have a system where you delay this. So initially a block is worth it's normal difficulty - as per usual.

But after 10,000 blocks.. beyond a re-org, you let it be worth what it's actually worth. This has some nice benefits (in my case - for pruning)
91  Bitcoin / Development & Technical Discussion / Re: Adding anti-theft feature to Bitcoin using a new address type on: June 13, 2018, 02:12:31 PM
Putting aside the FORK that this would take..

.........

An R-Address is a special address that is composed of 2 separate addresses.

One of the addresses is meant to be kept online (for fast payments), and one offline (secure). R-ON and R-OFF.

R-Address = HASH ( R-ON | R-OFF )

Spending with the R-OFF key lets you do whatever you want. This is only ever used after a hack.

Spending with the R-ON key means that you MUST send the funds to another special address, the S Address.
 
The S Address is also made up of 2 separate addresses.

One of the addresses is the user address S-USER, and one MUST be the R-OFF key from the R address.

S-Address = HASH ( S-USER | R-OFF )

Again, spending with the R-OFF key lets you do whatever you want, as soon as the transaction is confirmed. And again you would only use this after a hack.

Spending the S-USER address requires you to wait 144 blocks.

R and S addresses should be verifiable by the miners, so you can't just stick it all into an obscured P2SH.

Soo.. what this means is..

When a user receives funds from an R-Address he will need to wait 144 blocks before he can claim them. I think this is a non issue given the security implications of an un-hackable online hot wallet.

BUT - if a hacker steals the R-ON key (the exchanges online key), he MUST also send the funds to an S address. Then also wait 144 blocks. Enough time for the exchange to notice, and use the R-OFF key.
92  Bitcoin / Development & Technical Discussion / If you just SUM the inverse-hashes of valid blocks ..? on: June 13, 2018, 12:05:39 PM
..I'm working on something.

The inverse hash is the MAX_HASH_VALUE - the hash value. So the lower the hash of the block, the more difficult the block, the more you add to the total.

I'm wondering what the sum of the inverse-hashes of the blocks, as opposed to the sum of the difficulty of the blocks, would give you ?

You would still need to find a nonce that satisfies the block difficulty, as usual, but after that the lower your hash, the more your block is worth.

The chain with the most hash-rate would on average still have the highest sum of inverse-hashes.

Any ideas what would happen?

( It just seems that some of the POW available is being left unused.. )
93  Bitcoin / Development & Technical Discussion / Re: Is Lightning Network inherently flawed due to required 24/7 online on: May 01, 2018, 07:47:56 AM
Might point is for Bitcoin to be adopted for wide usage it needs to be as easy/convenient to use as current centralized options.

Bitcoin already is adopted for wide usage.  It has FAR more usage now than it did in 2013.  It had FAR more usage in 2013 than it did in 2009.

That's WHY we are talking about scaling and the related issues, BECAUSE bitcoin continues to be adopted for wider usage.

Build useful tools, the market will find ways to use those tools.  It is impossible to know what people will be doing in 10 or 20 years. Any attempt to predict the future of technology is futile. All we can do is build ever better tools that provide more options and then wait to see what the market does with those tools.

LN is just another tool providing yet another option.  Many people WILL be online when they are making their transactions.  As such, THOSE people will have LN as a low cost option to take nearly instant transactions off-chain without a centralized third party.  Doing so will free up space in the blockchain for those that need/desire a decentralized solution while they are offline, reducing congestion and cost on the blockchain.  Furthermore, as you've already pointed out, the "average person will choose to trust a third party". For low risk transactions and small values there are MANY people that will gravitate to centralized solutions for exchanging Bitcoin value. Those transactions ALSO will not be on the blockchain and will free up space for those that need/desire it.

There is no reason to think that additional tools won't be developed in the future to improve the scaling even more.

Perhaps someday everyone will be using Bitcoin every day.  Perhaps Bitcoin will never be more than a niche currency for special use cases.  Perhaps Bitcoin will become a backbone for settlement between local providers of value exchange. The point is for bitcoin to be a decentralized, global, trustless, permissionless payment system.  The market will decide the best use case for that system with the available tools at any moment in time.

On-chain doesn't scale, which is why we have LN, but to send money to an offline counter-party you can't use LN, so those types of payments don't scale because they have to be on-chain.

LN scales just fine for online transactions.

Offline transactions can choose between on-chain solutions, or centralized solutions, or whatever new tools are created in the future.  Do you have any good tools you'd like to suggest to allow offline, decentralized transactions at scale?  If not, then all we can do is wait until someone else comes up with one.  Meanwhile, we'll scale where we can.

People are going to make the decision to use Bitcoin based off of features.

And LN offers a new feature that wasn't there before.  As such, people that wouldn't have chosen Bitcoin before may choose to do so now.

For instance being able to can send money to anyone in the world easily and cheaply from their computer or phone and they'll have it in one hour and you don't have to wire the money or have have the same bank.

Or, being able to send money nearly instantly, easily, and cheaply from their computer or phone to anyone in the world that is online?

But if you can only do that when they are online with their LN running and you can only receive money the same way or instead do on-chain and pay what will eventually be untenable fees that means less utility, therefore less users.

The number of users will grow to match the utility.  LN adds utility, it doesn't reduce it. As such, the number of users will increase, not decrease. LN isn't taking away the ability to perform on-chain transactions, it is just adding an option for online (off-chain) transactions.

You're saying people can choose if they want to use bitcoin or a standard centralized service. Well of course. But isn't the point to get them to use Bitcoin, but that will only happen if the UX is as good as current options, and needing to be online 24/7 for LN cuts out an important use case for bitcoin.

I'm saying people can choose if they want to use bitcoin AS a "standard centralized service" (such as Coinbase.com) OR if they want to use bitcoin as an online instant service (such as with LN) OR if they want to use bitcoin as an offline approximately 1-hour service (such as with on-chain transactions) OR if they want to create a new tool for using bitcoin (their is no permission needed to create any tool you can think of).

It's that flexibility that allows bitcoin to grow and expand to the limits of what the users can think of for as long as it exists.

HAMILTON - YOU LOGICAL BEAST !

Very well said.

And as for not being online.. I know people who haven't missed a single minute of Clash of Clans in years .. I think they're going to be online to check their money.. ( we'll catch up later )

94  Bitcoin / Development & Technical Discussion / Re: Can you think of ways to use LN offline? on: April 14, 2018, 09:22:54 AM
The whole point of OFF_CHAIN txns is that you DON'T need to be connected to the network ( ON_CHAIN ).

If I go to the market, and no one has reception, I can still give you valid contracts that you can validate, independently. Phone to phone or whatever.

If one party does connect to the network and tries to spend the txn in an attempt to snatch your funds, then you will have a certain amount of time (the timelock) to logon and claim your rightful coins, and their coins aswell.. :p

Basically - I give StarBucks a valid transaction, that gives them $5. Then I want another coffee, so I give them another txn that gives them $10, both coming from our initial MultiSig setup txn (which is on-chain). They cannot spend both, as they use the same outputs, so they throw the first one away and keep the second (which is more valuable to them).

Neither of these touch the network (require you to be online), until someone wants to cash out.

You don't need to be online to sign / verify / swap a TXN.

95  Bitcoin / Development & Technical Discussion / Re: CoinSwap + CT = Truly Anonymous on: April 03, 2018, 09:11:33 AM
CoinSwap :

https://bitcointalk.org/index.php?topic=321228.0

In laymans..

Alice wants to pay Carol.

What actually happens is that Bob pays Carol, and then Alice pays Bob (sound familiar?). There is no link between any of the transactions, as the rules are enforced using off chain transactions, which never get published.

It uses a technique almost identical to LN to make sure Bob can't lose his money. (he doesn't pay unless he knows he's getting paid)

Honestly - Mr Maxwell invented off chain crypto-concepts  / atomic transfers / HTLC contracts right there. Even LN was hiding behind the punctuation. We just didn't realise it.. lol
96  Bitcoin / Development & Technical Discussion / Re: CoinSwap + CT = Truly Anonymous on: April 02, 2018, 08:28:54 PM
.. your idea already sort of exists.

PS. It's not my idea.

It's just

B.I.T.C.O.I.N

..

 Grin

..

..

god I love that bastard
97  Bitcoin / Development & Technical Discussion / Re: CoinSwap + CT = Truly Anonymous on: April 02, 2018, 06:42:15 PM
This idea has already been implemented and used in Monero with ring signatures and you can get a basic ELI5 version of it with this video some guy in the community made.

The only difference with what you are saying is that you aren't sending a transaction through only one person, but rather you are sending a transaction that is made possible by using past signatures on the blockchain as decoys, and only key images can help the recipient verify that the payment hasn't been sent before.

CT came afterward in terms for Monero, so before you were able to tell the coin amounts being transacted... but how the code is right now with everything in place and also about to be upgrading to a mandatory ring signature of 5 to 7, I'm not ashamed to be colored impressed every time I learn more about it.  Only problems is scalability, but with the possibility of adding bullet proofs on the horizon, it looks like it won't last that long.

Not trying to shill, just trying to say that your idea already sort of exists.

Hmm.. nope, I don't think so. CoinSwap is very different to Ring Signatures / CoinJoin.

In a Ring Signature ( or a CoinJoin ) the anonymity set is still the size of the inputs to the transaction. The inputs match the outputs in some fashion.

With CoinSwap the anonymity set is the size of ALL CoinSwap transactions going on at that time on the whole chain. This is potentially MUCH larger, especially if everyone started using it by default. So that ALL transactions were CoinSwaps.

With CoinSwap + CT - there would be ZERO information on-chain about who was sending what to who. You would pay X in secret, and they would pay Y (all done in such a way that no one can scam each other). There would be nothing linking your payment to Y.

The CT is required, because Without it, either you all send the same amounts ( not cool ) or it is obviously trivial to see which transactions are linked (check the amounts). But With it.. BOOM!
98  Bitcoin / Development & Technical Discussion / Re: Random Number On Blockchain on: March 31, 2018, 08:15:11 PM
Take the first bit of Hash(blockhash) of the last 64 blocks.

Make a 64 bit number. Hash That.

It's random.

Everyone can calculate it independently.

Right, but everyone will know what's the next number, of block 65. You add 0 or 1 to the previous 63 bits and get 2 possible results, which can't be called random, correct?

True..

Hash( next block hash ) better..
99  Bitcoin / Development & Technical Discussion / Re: CoinSwap + CT = Truly Anonymous on: March 31, 2018, 08:20:14 AM
I'd rather CT a CoinSwap than Schnorr a CoinJoin.. romantic fool that I am.
100  Bitcoin / Development & Technical Discussion / Re: CoinSwap + CT = Truly Anonymous on: March 29, 2018, 06:59:42 PM
CoinSwap already works on Bitcoin.

Once CT is activated.. It's ready.

The Only tricky bit is finding the person to participate with you in the CoinSwap, but this problem is FAR easier than the Lightning Network, so it shouldn't be too hard to sort out.

At a pinch, you could simply ask your direct peers on the BTC network if they have the funds available, and just use one of them.

Simples.
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 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!