AWARD-WINNING

CASINO CRYPTO EXCLUSIVE

CLUBHOUSE 1500+

GAMES 2 MIN

CASH-OUTS 24/7

SUPPORT 100s OF

FREE SPINS PLAY NOW Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here. Advertised sites are not endorsedby the Bitcoin Forum. They may beunsafe, untrustworthy, or illegal in your jurisdiction.

Frogolocalypse



Offline



Activity: 8

Merit: 0







NewbieActivity: 8Merit: 0 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 09:57:58 AM #2 While not specifically related to a PoW change, I would like to see whether there is something that might be investigated to provide more choice to users for any PoW implementation. I'm pretty sure this isn't a re-direct. Let me know if it is.



PKI Mining and Node relay. (Public Key Infrastructure Mining and Node Relay)



Would it be possible to add an encryption key to a txn that signals that you will only allow miners that have the key to mine your txns? This then might be solved as a configuration setting on the nodes :



1. Accept/relay all txns.

2. Key management solution within client that allows me to select from a list of miners that I, as a user, find acceptable.

3. I accept/relay txns that meet a library of keys (white-list).

4. Reject txns that meet a library of keys (black-list).



The immediate issue is that your txn would need to have several keys, for the list of pools/miners that you would be prepared to use to include your txns in a blocks. I'm thinking that there needs to be some method using nodes to re-direct around hostile miners, to miners that meet your requirements. GnuPGP provides the facility for using multiple keys to encrypt the same key. The miner defines a private key, generates a public key from that private key, and the user encrypts their transaction using the private key(s) of their choice.



This might not even be handled in any other way than a 'handshake' between nodes. When a node connects to another node, it passes along its white-list. Perhaps its black-list too, but not necessary. The node it has connected to can then replicate the transactions that meet the list. The node then weeds out the transactions that meet its black-list.



So how would a node perform its validation function with some or all of the content of txn encrypted? Would it be possible to use the public key of one of the encryption keys in order to do a blind validation? I can't see how that would work. Does anyone know of a model that would allow this?



The reason I like this type of option is that it is opt-in, which satisfies the ethos of bitcoin. Then there is incentive for miners to 'do the right thing' and be an accepted miner. You can have white-lists, and black-lists, managed by the user. But it also might give you control, as a node owner, to decide which txns destined to which miner are relayed through your node. I don't want my node to be used to relay transactions to that miner. I think it would also encourage for there to be more nodes.



This entire system doesn't deal with block propagation, so I think it would have a negligible effect on traffic.



But you'd also need to be able to remove transactions from your pool if they are in the block. So it sounds like you wouldn't be able to use encrypt all of the data, just some of it. Enough so you couldn't mine it, but not enough so that you couldn't identify it.



Definitely more cpu processing time though.



Reckon you could do it by making a hash of your transaction details, and then referencing that vs a hash of each of the transactions in the new block. Compare the two, and you'll know you can remove the transactions in the block with matching hashes. So whether all of the txn was encrypted or not, the hash is a header field that isn't. This would allow you to remove transactions in your pool when a new block confirms that they have been included in a block.



Think I might even be over-thinking the validation part. There are two validations. One of the txn, and one of the txn in a block. The second one isn't affected by this process. The first one is. BUT. Do I care about the first one much? The miner still has that key. They can decrypt the txns they have, validate them, and therefore include them in blocks. So the issue doesn't become is it validated, but of incentives.



Validation would still be issue for txn at node though. Spam. Adversarial users could create transactions that clog nodes that will never be included in blocks. If the transaction is invalid, but the relaying node can't validate it, they'd be replicating it to all of the nodes You'd need to have some method of making the user has to pay for this type of transaction. So they lose money the more of them that they create.

sturle



Offline



Activity: 1444

Merit: 1001



https://bitmynt.no







LegendaryActivity: 1444Merit: 1001https://bitmynt.no Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 11:28:19 AM #4 I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.

I buy with EUR and other currencies at a fair market price when you want to sell. See

Warning: "Bitcoin" XT, Classic, Unlimited and the likes are scams. Don't use them, and don't listen to their shills. Sjå https://bitmynt.no for veksling av bitcoin mot norske kroner. Trygt, billig, raskt og enkelt sidan 2010.I buy with EUR and other currencies at a fair market price when you want to sell. See http://bitmynt.no/eurprice.pl Warning: "Bitcoin" XT, Classic, Unlimited and the likes are scams. Don't use them, and don't listen to their shills.

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 11:50:23 AM #5 Quote from: sturle on March 19, 2017, 11:28:19 AM I think a hardfork change is too drastic, and will certainly end in a contentious hard fork. A POW change light can be implemented as a soft fork by a requirement for an extra proof of work of a different type in the coinbase transaction or in another special transaction. This will encourage cooperation between miners having lots of specialized SHA256 hardware and users mining the extra proof of work on their CPUs. If miners behave badly, users will turn their backs to them, and it will become more difficult/expensive for the miners to create new blocks. Another important advantage is that old nodes and wallets will still work, as long as the majority of the hashrate is behind the soft fork. Still safeguards must be put in place to stop someone with a very large SHA256 hashrate to overtake the main chain at a later time when the extra POW difficulty is high, since a SHA256 only chain will still be valid for old nodes and SPV nodes.



Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.





Judging from this latest tweet, we may need to prepare for the worst...





https://twitter.com/JihanWu/status/843341104531427336



Quote from: Jihan I found that the HF future contract of Bitfinex is very unfair against big blocker. 2 support BU supporter, HF should be accelerated.

Good thoughts but miners will never approve this proposal with BIP 9 and I doubt even 51% so would need to be a UASF , whicj will likely end up as a HF only . This proposal is more of a HF in reaction to a 51% attack from miners which would not be as controversial.Judging from this latest tweet, we may need to prepare for the worst...

belcher



Offline



Activity: 261

Merit: 328







Sr. MemberActivity: 261Merit: 328 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 01:22:19 PM #7 It is good to be prepared for any eventuality. Just because we talk about a PoW hard fork doesn't mean we'll use it on a whim.



A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.

- CoinJoin that people will actually use.

PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129 1HZBd22eQLgbwxjwbCtSjhoPFWxQg8rBd9 JoinMarket - CoinJoin that people will actually use.PGP fingerprint: 0A8B 038F 5E10 CC27 89BF CFFF EF73 4EA6 77F3 1129

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 01:57:24 PM

Last edit: March 19, 2017, 02:09:38 PM by BitUsher #9 Quote from: belcher on March 19, 2017, 01:22:19 PM It is good to be prepared for any eventuality. Just because we talk about a PoW hard fork doesn't mean we'll use it on a whim.



A good thing would be to have some script somewhere tracking blocks and transactions, so that if any big censorship re-orgs happen then it can be proved to the public.



Yes, we should only use this after an attack occurs, but need to test and prepare now. If anything showing we are prepared is likely to prevent an attack in the first place.



https://twitter.com/petertoddbtc/status/843450186416365569







Quote from: Cryptorials on March 19, 2017, 01:38:31 PM Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?



A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.



My advice it to first test and get running a testnet version of simple PoW Keccak with 0.14 and than investigate a Hybrid SHA256/Keccak proposal ... and after these are running on a testnet with individuals actively mining we can start to explore a PoW /PoS hybrid.





Yes, we should only use this after an attack occurs, but need to test and prepare now. If anything showing we are prepared is likely to prevent an attack in the first place.A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as noPoS really exist and politically adding PoS to bitcoin will be much more difficult.My advice it to first test and get running a testnet version of simple PoW Keccak with 0.14 and than investigate a Hybrid SHA256/Keccak proposal ... and after these are running on a testnet with individuals actively mining we can start to explore a PoW /PoS hybrid.

Cryptorials



Offline



Activity: 691

Merit: 504





Cryptorials.io







Hero MemberActivity: 691Merit: 504Cryptorials.io Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 02:08:10 PM #11 Quote from: BitUsher on March 19, 2017, 01:57:24 PM Quote from: Cryptorials on March 19, 2017, 01:38:31 PM Instead of PoW change could it be possible to add a supplementary PoS layer which requires a block to be validated in some way by nodes prior to miners being able to build the next block, reducing the centralizing effect of propagation times?



A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as no secure PoS really exist and politically adding PoS to bitcoin will be much more difficult.





A hybrid PoW / PoS version should be investigated as well, my only concern is that we should keep the PoW HF as simple as possible and adding a "secure PoS" algo into the mix will be sure to complicate the HF as noPoS really exist and politically adding PoS to bitcoin will be much more difficult.

I'm glad you think its worth looking at, thanks.



The benefit I think is that miners will fight a PoW change tooth and nail and may gain some sympathy for that from users, because it is a little bit unfair to miners even if it does have benefits and will look to many like a major change. If miners fight such a supplementary PoS they are transparently only doing so in the self-interest of big pools trying to centralize power. So perhaps it won't be more difficult politically.



Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization? I'm glad you think its worth looking at, thanks.The benefit I think is that miners will fight a PoW change tooth and nail and may gain some sympathy for that from users, because it is a little bit unfair to miners even if it does have benefits and will look to many like a major change. If miners fight such a supplementary PoS they are transparently only doing so in the self-interest of big pools trying to centralize power. So perhaps it won't be more difficult politically.Also perhaps security is less of an issue for PoS if it could be structured as a supplementary layer which doesn't actually secure transactions, only serves to reduce centralization? Cryptorials.io: A blog about Bitcoin and other decentralized technology

freebutcaged



Offline



Activity: 588

Merit: 541







Hero MemberActivity: 588Merit: 541 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 02:31:24 PM #13 Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network and secures the blockchain by mining exactly every 10 minutes with blocks of any size up to even 16MB?



I want to know what happens if there was only one mega pool mining and then rewarding miners based on their hash rate?

BitUsher



Offline



Activity: 994

Merit: 1027







LegendaryActivity: 994Merit: 1027 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 02:35:42 PM #14 Quote from: freebutcaged on March 19, 2017, 02:31:24 PM Instead change the mining algorithm or the way blocks are mined, maybe even develop a secondary software to take all the combined hash power of the entire network



The combined protocol would simply become the new protocol and thus this is essentially over complicating matters.



A simple change in this case has 3 unique advantages:



1) breaks less software code (APIS, firmware, custom apps , wallets, ect... )

2) Is less likely to contain exploits and easier to secure

3) Is less likely to contain propositions people disagree with and can argue over.... if we are being attacked by the miners and a speculative coin vote fails than we have no choice but to perform a HF and we don't want to add anything to the HF that would leave others behind because they disagree with part of the proposal



Quote from: freebutcaged on March 19, 2017, 02:31:24 PM mining exactly every 10 minutes with blocks of any size up to even 16MB?



Sounds to me like extension blocks for more capacity, but that is outside the scope of this topic.

The combined protocol would simply become the new protocol and thus this is essentially over complicating matters.A simple change in this case has 3 unique advantages:1) breaks less software code (APIS, firmware, custom apps , wallets, ect... )2) Is less likely to contain exploits and easier to secure3) Is less likely to contain propositions people disagree with and can argue over.... if we are being attacked by the miners and a speculative coin vote fails than we have no choice but to perform a HF and we don't want to add anything to the HF that would leave others behind because they disagree with part of the proposalSounds to me like extension blocks for more capacity, but that is outside the scope of this topic.

Atroxes



Offline



Activity: 121

Merit: 100









Full MemberActivity: 121Merit: 100 Re: [ANN] Bitcoin PoW Upgrade Initiative March 19, 2017, 03:51:48 PM #17



Quote from: Bitcoin: A Peer-to-Peer Electronic Cash System, Section 6 The incentive may help encourage nodes to stay honest.

If a greedy attacker is able to assemble more CPU power than all the honest nodes,

he would have to choose between using it to defraud people by stealing back his payments,

or using it to generate new coins.



He ought to find it more profitable to play by the rules,

such rules that favour him with more new coins than everyone else combined,

than to undermine the system and the validity of his own wealth.

Since most of you obviously haven't read it, let me direct your attention to Section 6 of the Bitcoin white paper