Hi all,
I’m looking paper reviews: http://hrobeers.be/papers/P2TA.pdf
I’ve been brainstorming for implementation detials for Peerchemist’s PSA proposal and came up with this concept.
It might already exist, but I haven’t found something similar yet.
Please review and let me know if this is nothing new.
Thanks,
hrobeers
cool stuff, you ve already mentioned it before, but seeing it in on paper now makes it all more clearly.
question: is it not the trend to put it on github nowadays?
question 2: to be meta squared, does it make sense to there be some sort of global list of all spawn decks such as PeerAssets/deck spawning xxx; Bitcoin/deck spawning xxx?
Do you mean the paper? It is in a private git repo for now, will make it public when this papers is reviewed.
Or do you mean a reference implementation?
So the idea is that all deck spawning transactions would have the same tag: “PeerAssets/deck spawning”, which would function as some sort of global list. Do I need to clarify this more in the paper?
yeah I meant the paper, like all those BIPs or the satoshi paper: http://nakamotoinstitute.org/bitcoin/
to clarify 2:
Would there be ever a need for a list of lists?
Like you can have a domain and a sub-domain in a url e.g.: pizza.com and dominos.pizza.com
so there is a supertag ‘AllAssets/deck spawning’ linked to ‘PeerAssets/deck spawning’
o and what about malicious intent? It seems very easy to make spam the ‘PeerAssets/deck spawning’ with domain squatters like we did have in the early 90’s . Well it is still quicker than looping the entire blockchain :-/
This is an excellent way to query spawned PeerAssets decks. It seems that implementing PeerAssets protocol by utilizing existing block-explorers is now a very real idea! Multi tagging with separate “PeerAssets/deck spawing”+salt_1 and “PeerAssets/my asset”+salt_2 tags and reducing the amount of transaction lookups when querying is great.
Looks great, I’ll try to make something similar using github-pages.
[quote=“thehuntergames, post:4, topic:3849”]to clarify 2:
Would there be ever a need for a list of lists?
Like you can have a domain and a sub-domain in a url e.g.: pizza.com and dominos.pizza.com
so there is a supertag ‘AllAssets/deck spawning’ linked to ‘PeerAssets/deck spawning’[/quote]
A system like that would be cool. If you have an idea how to do it, I’m open to it.
I have one possible implementation:
Let’s say we have a seperator “/”. The spawining txn can then have tags:
PeerAssets
PeerAssets/my asset
PeerAssets/my asset/subtag
At this point, a discovering client only knows about the “PeerAssets” tag. It can then start to brute force the “my asset” tag, and after that the “subtag”. This could work quite well if the same salt is used for all tags and the subtag length is limited so that the client can decide that a specific address is not a tagged address.
Please tell me what you think of this and I might add a section for it.
I have no good way to avoid tag spamming, ideas are welcome.
Peercoin’s txn fee might help here a bit as every tag increases the txn size.
There might be a possibility to do something like hashcash.
We could agree that the output after the P2TA output encodes the hashcash nonce.
However, this would still not prevent spamming the tag address.
I fear that there is no good way to prevent spamming on a PeerAsset like application as there is no way to prevent messages to be relayed by standard nodes.
If anyone has a good idea here, I’ll be happy to integrate it in the paper.
just a quick thought, dont kill me if it makes no sense: what if we could use of some the ideas from HD bip 32 https://en.bitcoin.it/wiki/Deterministic_wallet
so basically 1 seed that produces sub seeds?
the superseed is made with a tag, the derived keys from the seeds are thus have a hidden link to its parent.
maybe these derived keys can be used with an addition spawn tag or something…
Interesting thought.
The first address in a tree can indeed be deterministically generated from a tag.
Unfortunately all derived addresses can’t have a tag encoded in them. So it’s not really suitable for derived tags.
We might however use the wallet chains as a way to chain the Asset transactions. If besides the tagged address output, we add another output to the next address in the wallet chain, we have an other way to walk the asset transactions.
The difficulty here would be to avoid multiple transaction branches using the same wallet chain branch.
[member=30983]peerchemist[/member] might step in here to see if there is a use case for this.
Is this a bit what you are trying suggest?
Looking at 
from https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki
one can see it begins with a seed say ‘PTSA’
from here it shows that each dept has different meanings, ending with addresses at depth = 3.
this looks very much as a composite pattern in which each node can have nodes.
so your proposed salt could be dept =1 while a deck spawn could be at depth = 2
For the sake of quick querying, one could either use the tagging system and or generate the addresses at dept =3 query those
something like this? ???
no wait,
at depth 1 you have the list of decks
at depth 2 decks
at depth 3 you start tagging the transactions
An application can decide to do that indeed.
However, I do not see the advantage over using a plain tag.
To avoid tag spamming, we could use Proof of Burn.
This would require to generate the public key from the tag making the transaction unspendable.
When a tag is queried, only the incoming outputs with a value above a threshold should be considered.
What do you think of this?
[quote=“hrobeers, post:11, topic:3849”]To avoid tag spamming, we could use Proof of Burn.
This would require to generate the public key from the tag making the transaction unspendable.
When a tag is queried, only the incoming outputs with a value above a threshold should be considered.
What do you think of this?[/quote]
I would not go too far. It is best to do nothing about spamming or squatting. It will not matter anyway, spammer will cause no harm at all to the PeerAsset aware nodes nor Peercoin network.
okay, KISS it is.
Since this is meant not only specific to peercoin, you could start with
Assets (so you can have a list of Assets)
Assets/PeerAssets (so you can have a list of PeerAssets)
Assets/PeerAssets/mydeck (so you can have a list of deck transactions)
[size=14pt]Draft number 2![/size]
http://hrobeers.be/papers/P2TA.pdf
I updated the paper with some “tag spamming” counter measures.
Please review.
I’ll update the PeerAssets use case to include one some tag spamming counter measures after they are reviewed.