Pages:
Author

Topic: [ANN][COMB] Haircomb - Quantum proof, anonymity and more - page 16. (Read 7118 times)

newbie
Activity: 17
Merit: 0

edit3: can anyone graph the supply over time on a chart? for example desmos?
would love to see how the supply goes over time. to see how much will the reward claim be at 50k blocks from now, 100k blocks, ect.
to see how the reward is effected over time.
thanks!

I'd like to see this too. I looked into it and tried using Desmos but didn't work, and I think the floor part is Javascript "Math.floor()" function but I'm not a programmer, could be totally wrong

"MAX(2.1-FLOOR((LOG(h)/LOG(2))^6)/100000000, 0)
max is 12423823.18141419
and h is block number can start at current block"

newbie
Activity: 71
Merit: 0
noticed there has been a bunch of 546 sat txs surrounding this address lately 1HckjUpRGcrrRAtFaaCAUaGjsPx9oYmLaZ

any idea if it has anything to do with comb? what other reason would there be for specifically so many 546 sat tx's

looks like the 90mb bomb from a few days ago also had something to do with 546 sat tx's (if not mistaken)

newbie
Activity: 17
Merit: 0
unless theres something im completely missing.

You (and others) might be thinking that I've completely lost my mind but let me reassure you that I am not crazy.

Yes, you're missing liquidity stacks. They are completely unusual feature in a crypto currency. Complete breakthrough.

In several years it's going to be completely normal to pay to 1000, 10000, or even 1 000 000 people using one payment, but currently that is not normal, it is not possible with almost all crypto currencies and this is why people do not think it's even possible.

But let me repeat again, it is actually possible.


Proof:

Suppose you want to pay 1000 people and you have their addresses.

You create a liquidity stack with 1000 entries, each entry specifies the next entry, the person's address, and the amount you pay to each of the people.

You end up with the first persons liquidity stack address.


Next you create a normal haircomb transaction from your address to the liquidity stack. NOT to the person. But to the liquidity stack!!!


This gives you 21 bc1q addresses that you need to fund on the bitcoin network.

Once these 21 addresses are funded on bitcoin blockchain (this is a small transaction) the 1000 people have been paid.


Only thing that remains is to give the transaction history to the 1000 people (the same to every person). But remember this does not happen on the blockchain, so it does not matter how large this history is.

Large history size is not a problem and there is no limit how huge the history can become.


When the receivers validate their coins they really own them.



That's interesting, sounds like you've really thought of everything. Where can I see liquidity stacks explained? But how will you give the coin history to everyone without essentially defeating the purpose of the privacy coin?
copper member
Activity: 82
Merit: 5
unless theres something im completely missing.

You (and others) might be thinking that I've completely lost my mind but let me reassure you that I am not crazy.

Yes, you're missing liquidity stacks. They are completely unusual feature in a crypto currency. Complete breakthrough.

In several years it's going to be completely normal to pay to 1000, 10000, or even 1 000 000 people using one payment, but currently that is not normal, it is not possible with almost all crypto currencies and this is why people do not think it's even possible.

But let me repeat again, it is actually possible.


Proof:

Suppose you want to pay 1000 people and you have their addresses.

You create a liquidity stack with 1000 entries, each entry specifies the next entry, the person's address, and the amount you pay to each of the people.

You end up with the first persons liquidity stack address.


Next you create a normal haircomb transaction from your address to the liquidity stack. NOT to the person. But to the liquidity stack!!!


This gives you 21 bc1q addresses that you need to fund on the bitcoin network.

Once these 21 addresses are funded on bitcoin blockchain (this is a small transaction) the 1000 people have been paid.


Only thing that remains is to give the transaction history to the 1000 people (the same to every person). But remember this does not happen on the blockchain, so it does not matter how large this history is.

Large history size is not a problem and there is no limit how huge the history can become.


When the receivers validate their coins they really own them.

newbie
Activity: 71
Merit: 0
You mean for a faucet or something?

Yeah I'm thinking about paying 0.00000001 COMB to every single person alive. It's possible with today's tech. Only problem is getting the massive list of addresses.

even if you had 6billion addresses one for each person alive.
thats 6billion tx's that you need the btc network to do for you.
with 7 tx per second on avg, thats 604k tx per day, thats over 9k days, and over 27 years.
thats if you were the only one making txs on btc.

even if you give that double by making your tx's smaller somehow, thats still over 13years of blocks.
lets say you can even make your txs smaller then that by half, thats still over 6 years of blocks.


so even if you can make btc network produce 28tx's per second, and you had nobody else competing with you for block space. that would still take 6yrs of blocks.
this would cost an enormous amount in fees alone. aside from it not being practical in anyway.
unless theres something im completely missing.

so maybe its better to think of more realistic goals.

how does this even cross your mind?

makes me look at the whole project differently...
copper member
Activity: 82
Merit: 5
You mean for a faucet or something?

Yeah I'm thinking about paying 0.00000001 COMB to every single person alive. It's possible with today's tech. Only problem is getting the massive list of addresses.
newbie
Activity: 17
Merit: 0
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?




You mean for a faucet or something?
newbie
Activity: 71
Merit: 0
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?




Re-read the whole thread.
Have no idea what your talking about.
 Grin
copper member
Activity: 82
Merit: 5
Hello. Recently I've been thinking a lot about this.

Suppose someone had 77.5 COMB what would that person do with them?

If you read this thread carefully then you probably know what I mean.

I know it would be really complicated and some people could pose like two people and so on.

But suppose the final list could be assembled. How would you deliver that list to the person and then back the transaction history?


newbie
Activity: 71
Merit: 0
having an issue now where the qt client says "done loading" and just stays like that. i did everything correctly as far as i know and shut down the proper way, but on startup. after verifying blocks, just says done loading and either freezes there or just closes after some time.

edit:
might of corrupted the commits.
ill try give it another new sync, and will test again.
could be error on my part somewhere

edit2: fully synced everything working

edit3: can anyone graph the supply over time on a chart? for example desmos?
would love to see how the supply goes over time. to see how much will the reward claim be at 50k blocks from now, 100k blocks, ect.
to see how the reward is effected over time.
thanks!
copper member
Activity: 82
Merit: 5
PRUNING

Pruning is supported. Set prune=1 in your bitcoin-qt and restart it. This will enable manual prune.
Next open core command line and enter:

pruneblockchain 481822

Then wait till a number appears. Once it appears about 100 GB of ancient blockchain data was deleted.

This is especially useful/crucial for SSD disk users.


Next, 3 advises.

1. The commits.db should be backed up when both the wallet and bitcoin-qt is correctly shutdown. Not while it is running.

2. If you need to restore backup commits.db, do it when both the wallet and bitcoin-qt is correctly shutdown. Not while it is running.
 
3. The Sending commitments screen exists because haircomb core upon startup detected that your commits.db is corrupt and it is recreating a new one. Possible reasons:

  • you shut down your pc while core was running - don't ever do this
  • the wallet crashed due to problem that I caused - improbable - you will see error in the comb window and then it will close
  • you shut down your core improperly - don't ever do this

I also strongly advise everyone to manually fully save your wallet to a file as often as needed because the wallet has no auto save feature - it was easier to develop that wallet in this way.

I already dodged a bullet several times using this method.

it is you who is responsible for saving your own wallet to a files of your choice as often as needed but especially every time after creating new keys and new liquidity stacks.

newbie
Activity: 71
Merit: 0
what for?

ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?

No no I don't mean I claimed that many, I don't know how many I claimed (maybe even 0) because my wallet isn't synced. But the addresses were posted somewhere else and I saved them so I could see what fee they used when I was trying to claim. The wallet will take too long for me to sync (slow connection and computer) so I gave up with that for now. But maybe they will help you work out what kind of txs work best when claiming. I tried looking when I was claiming but I'm not technically proficient enough to know if any were odd etc.

Sure make a pastebin. Would love to take a look at successful claims to see more info.
Are these your 3k attempts? or where did you find this list.
newbie
Activity: 17
Merit: 0
what for?

ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?

No no I don't mean I claimed that many, I don't know how many I claimed (maybe even 0) because my wallet isn't synced. But the addresses were posted somewhere else and I saved them so I could see what fee they used when I was trying to claim. The wallet will take too long for me to sync (slow connection and computer) so I gave up with that for now. But maybe they will help you work out what kind of txs work best when claiming. I tried looking when I was claiming but I'm not technically proficient enough to know if any were odd etc.
newbie
Activity: 71
Merit: 0

only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info


I have a list of 3000 successful comb claims if you want I can email you it or something or post it in a pastebin 


what for?
ill sync my client it should be done in a few hours, and i will be more careful to save the commits.db and shut it down properly.

how do you know those 3000 are successful? if you dont have a fully synced node?
wow thats alot! what was your average price in fees did you use? sat/byte?
did you find any patterns or better times to claim?
any specific strategy you used?
how much sat per tx average per claim?
newbie
Activity: 17
Merit: 0

only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info


I have a list of 3000 successful comb claims if you want I can email you it or something or post it in a pastebin 
newbie
Activity: 71
Merit: 0
Is there a way to check if you have successfully claimed or not without the wallet being synced? The Comb Rewards Viewer site seems to be broken (unless it requires the wallet to be synced).



only way i was able to check is from full sync. i had it going yesterday, but i guess the commits.db didnt save so resyncing it again today.

still not 100% sure how it exactly works, since ive noticed times when i used low sat/byte and i was really far down in the block, and had many other tx's to bc1 addresses that were also p2swh txs but i still got the claim. edit: meaning other txs payed higher fee and were ontop of mine and also to bc1 addresses and also p2swh but i still got the claim

so im wondering what explorer i can use to identify which exact type of tx will work for a claim, this way i can scout previous blocks and see whats going on to somehow predict the network activity that the next block might bring.

currently i used blockstream.info
newbie
Activity: 17
Merit: 0
Is there a way to check if you have successfully claimed or not without the wallet being synced? The Comb Rewards Viewer site seems to be broken (unless it requires the wallet to be synced).

newbie
Activity: 71
Merit: 0
ive noticed when shutting down the wallet, then turning it back on, it takes a long time "sending commitments press q to shutdown x%"
is this normal? does this always take a long time when restarting the client? is there anything that can be done to speed that up? i mean after having a fully synced node, and restarting same thing takes forever to load back up

edit:
looks like forgot about this step
"general usage - shutdown

1. close bitcoin core, wait until the close window disappears.
2. go to 127.0.0.1:2121 and press safe shutdown. The wallet should close.

general usage - startup

1. start combfullui.exe
2. go to 127.0.0.1:2121, verify it is running
3. start bitcoin-qt.exe

general usage - commits.db database backup

1. shutdown bitcoin core, then safe shutdown combfullui.exe
2. copy commits.db to a backup location while the wallets are shutdown."

will make sure to copy the commits.db this time, and shut down properly.

newbie
Activity: 71
Merit: 0
looks like from natasha previous answer that yes to send comb from one address to another 21 burnt addresses need to be funded,
though it seems it doesnt have to be a single tx, and instead can be a multiple output tx, so funding 21 burnt addresses can be sending and receiving of multiple addresses,

yes we are early, Wink

newbie
Activity: 17
Merit: 0

what do you think is a fair price? how bout 50k sats

edit2: what happens to a failed attempt? i see the mining address is not shown in the wallet anymore, can i still use the same mining address to try again?
or only can use a new one?
Maybe some paid much less in fees so someone might sell for cheaper. I'd like to buy some Comb too but it seems we're pretty early.

You can't use the same mining address twice even if the first claim was unsuccessful. I wasted some btc attempting it (sent about 40txs, lol). And if someone else (a non Comb address) claims the Comb from the block then that Comb is burned since they can't access it. I think the best way to claim is by checking the mempool for the highest fee and then paying more than it, so if you know of any good sites to check for that then I'm interested to hear it.

Did you find out if when sending 1 Comb you have to send 546 sats to 21 addresses by the way? Pretty interesting if so because every time Comb is sent then BTC would be burnt simultaneously. I haven't tried to send any yet.
Pages:
Jump to: